Skip to content

QuantumGate Overview

Karel Donk edited this page Aug 24, 2018 · 22 revisions
Clone this wiki locally

QuantumGate is a peer-to-peer (P2P) communications protocol, library and API.

The long-term goal for QuantumGate is to become a platform for distributed computing based on a mesh networking model. In the short term, the goal is to provide developers with networking technology that they can easily integrate and use in their own applications.

The idea behind QuantumGate began taking shape in the year 2005 and early development in C/C++ began in late 2005. By early 2006 a document was written outlining the long term goals for this platform. This document is available in this repository and you can download it by clicking here (PDF).

Development stopped in 2007, and it wasn't until early 2017 when it started again from the ground up. The document mentioned above, although a bit dated, gives a very good idea of what the final platform is going to become.

You'll note that the document mentions the fact that developers will be able to create extenders that can run on top of QuantumGate, which will provide various services on the network. In 2017 the decision was made to also allow developers in the short term to integrate QuantumGate directly into their own applications (instead of it running separately) and make it available as a library and API. By doing that developers can customize QuantumGate to suit their specific needs, and can build fully customized applications for clients and consumers. Instead of writing your own networking library and dealing with low level communications and cryptography, QuantumGate can take care of that for you.


QuantumGate nodes behave as equal peers and can simultaneously function as both clients and servers to other nodes on the network. The local node is also referred to as the "local instance" while other nodes are referred to as "peers".

A QuantumGate node consists of the following main components:

  • QuantumGate Kernel. Also referred to as the local instance. This performs low level operations like connecting to the network and handling communications based on the QuantumGate protocol. Other tasks include finding peers on the network, maintaining a list of peers and routing messages on the network. This is essentially the gateway to the network. When you use the QuantumGate library and API to build your own application, you can enable or disable some of the functionality to suit your needs.

  • QuantumGate Extenders. These are software components that run on top of the local instance and can provide various services and functionality on the network. Examples of this are file sharing, instant messaging and even crypto-currencies. When you use the QuantumGate library and API to build your own application, you'll be writing at least one extender to handle the communications for your application.

  • Database. The database can be integrated or run separate from the local instance and is used to store any data the local instance needs to maintain, such as settings, peer information, and also any data that the extenders need to maintain. When you use the QuantumGate library and API to build your own application, you'll likely be using your own means of storing data and settings, and the QuantumGate API provides interfaces for retrieving settings and adding them back later.



By default QuantumGate compresses communications between nodes on the network. Developers of extenders can choose to disable compression when it makes more sense for their particular service (for example when the data that such an extender sends over the network is already compressed, or, when speed is more important).


Except for the initial phases of the connection handshake (in certain cases), QuantumGate encrypts all communications between nodes by default and this cannot be disabled. A number of encryption algorithms are supported, including post-quantum algorithms. The initial handshake requires two key-exchange phases using two ephemeral asymmetric key-pairs to arrive at symmetric session keys that are unique for every connection. In addition, the symmetric session keys are periodically updated during the lifetime of a connection via a key update procedure, also consisting of two key-exchange phases using two ephemeral asymmetric key-pairs to arrive at new symmetric session keys that are used from that point forward.


QuantumGate provides two ways for authenticating peers. As part of the connection handshake, QuantumGate has an authentication phase where nodes can authenticate each other based on their peer UUIDs (Universally Unique Identifier) and associated public key. Secondly, QuantumGate also supports using a Global Shared Secret requiring connecting peers to know this secret before they can successfully connect to the local instance. These options can be used separately or together for best security.

Padding and Cover Traffic

QuantumGate provides a few configurable options for padding data being sent over the wire in order to hide the exact length of communications. And in order to hide the amount and frequency of communications, and to make traffic analysis more difficult, QuantumGate can provide cover traffic at configurable intervals, referred to as "noise".


QuantumGate supports relayed connections and can route messages through a variable number of other (randomly chosen) nodes before reaching its destination. Relayed connections can even be established through (a combination of) other relayed connections. This helps to ensure that it will be very difficult to determine the original source and destination of information. Nodes pass along messages on the network without knowing exactly where it came from, and without knowing exactly where its final destination is. This leads to more privacy, and if desired, anonymity.‡

Routing Gateways

QuantumGate not only functions as a gateway for the extenders that it hosts, but through the support of relays can also function as a gateway for other nodes through which they can route messages and communicate with other nodes on the network. It's possible to set up dedicated gateways as well; these are instances of QuantumGate (without any extenders), which do nothing but route messages from one node to another.



Most of the critical operations within QuantumGate are designed to work with high levels of concurrency and parallel processing. QuantumGate will take advantage of multi-core processors whenever they are available. All extenders running on top of a QuantumGate instance will automatically benefit from this and developers will need to ensure that they write their extenders with concurrency and parallel processing in mind. Apart from speed this will also contribute to scalability.


QuantumGate is designed and will be built from the ground up with scalability in mind. Because QuantumGate is built up out of 3 main components, each of these components can be scaled up in hardware or software as required. For example, if QuantumGate should be able to handle more connections at once, the kernel software can be placed on a more powerful computer or a cluster of servers which are able to handle the load. The database can be placed on its own cluster of servers which are dedicated to the database functionality. Each of the QuantumGate extenders can run on their own server or cluster of servers if needed. But all of them can run on a single computer without any modifications as well.‡


QuantumGate is designed with many possibilities for extendibility. These possibilities can be used by developers to create their own services on top of QuantumGate, or to extend existing services. Using the QuantumGate library and API it's even possible to integrate QuantumGate into a completely new and different application.

Security and Privacy

QuantumGate is built with high levels of security and privacy in mind. All memory used by QuantumGate is sanitized and sensitive data is kept in protected memory buffers. Communications are encrypted by default, information is only shared when absolutely required, and when developing their own applications and/or extenders, developers can choose the level of security and privacy that they want to support.


QuantumGate is designed to make it very difficult to have a single point of failure on the network. Nodes can join in and leave at any time without any significant impact on the network itself. Due to the very distributed nature of the network, it will also be impossible to have a single point of attack to bring (certain services on‡) the network down. In addition, QuantumGate's (attack) tolerance levels are configurable and it maintains a reputation score for peers and endpoints on the network in order to take appropriate measures when they misbehave. By default the local instance is designed to be very unforgiving and has a very low tolerance for anything that looks like an attack.

‡ Depending on the extender(s).