QAN Private Blockchain
How to install QAN Private Blockchain
This document describes the installation procedure of the QAN Private Blockchain.
Hardware requirements
The hardware requirements are relaxed compared to the capabilities of the product. While it surely requires more computing power to run full-fledged virtual machines, quite a lot of consumer grade hardware is capable or running QAN Private Blockchain, including more than 12 year old+ CPUs like the Intel i5 2nd generation.
The actual hard requirements without which the software will absolutely refuse to run are the following:
12 GB of memory (16 GB highly recommended)
4 CPU cores (6+ cores highly recommended)
x86_64 CPU architecture
Hardware based virtualization support in CPU:
VT-x for Intel
AMD-V for AMD
Nested virtualization support
Software requirements
Since QVM runs deterministic and hardware isolated virtual machines, some specific kernel modules are required. This means that while QAN Private Blockchain is fully containerized and is aimed to be a first-class citizen in microservice architecture based systems, it won’t launch in a consumer level Docker for Desktop environment, since that does not support nested virtualization as per below picture taken from the Docker documentation:
More details are available in the official Docker documentation.
To overcome these limitations on all x86_64 platforms including Windows, macOS and Linux, regular virtual machines can be launched using popular and robust virtualization solutions from VMware and Oracle. See the support matrix to find out which software works best for your platform:
*if you use these pieces of software for business related activities you might need to purchase a licence. Always do your own research based on your specific use-case.
Downloading the QAN Private Blockchain software
The package is distributed as an Open Virtualization Format archive, which is easily consumable by aforementioned recommended Virtualization tools in a form of a simple import process.
The OVA archives are published in one of QANplatform’s GitHub repositories, available for a direct download.
Importing the downloaded QAN Private Blockchain software
Each Virtualization software vendor provides documentation for this standard import procedure:
Windows
macOS:
Linux:
Start the imported QAN Private Blockchain software
Once the import procedure succeeded, it will show up in your virtual machine library. The only thing left is to start the VM by pressing the “Play” button.
As the virtual machine boots it will complete all necessary initialization procedures automatically.
Interacting with the running QAN Private Blockchain software
The whole architecture is visible inside this public GitHub repository of QANplatform. Probably the most simple and straightforward multi-node blockchain setup, with well documented components and procedures.
The “examples” directory contains real-world examples how to deploy and interact with smart contracts. Additional examples both in other programming languages and for different purposes will be added continously.
Included components
QANplatform ships the whole blockchain experience with QAN Private Blockchain software. The following components are made available by the default manifest files through public container registries:
Node
This is the most fundamental piece of software, the blockchain node. It is responsible for:
Peer-to-peer communication with other participating nodes
Accepting, vetting and propagating received transactions
Compiling smart contracts written in any language
Receiving smart contract deployments and persisting them after compilation
Executing smart contract calls received via transactions
Accepting and managing XLINK cross signatures
Many-many other operations happening under the hood
The shipped distribution includes three nodes, which is the recommended minimum for doing anything resembling real-life operation.
QVM manager
This component does the heavy lifting. It spawns a pool of tiny actual CPU supported, hardware accelerated Virtual Machines (hence the requirements detailed in the first chapter) and makes them available to the nodes.
These small footprint VMs are responsible for compiling and executing QVM contracts, which can be written in any language, unlike on any other blockchain.
The bundled example includes a single QVM manager which will launch 4 sub-VMs (and this is why nested virtualization support is a hardware requirement too) with one vCPU cores each.
This is a networked service, which means it can scale exceptionally well if more dedicated QVM executor nodes are added.
XLINK signers
XLINK signers create cross signatures using Elliptic Curve and Post-Quantum cryptography. These are the components which enable us to operate fully compatible with the whole blockchain ecosystem and remain secure until and after the quantum problem practically impacts the whole market.
Again, mimicking a real-life scenario, each included node is bundled with an XLINK signer, which periodically submit signatures for them.
Visual explorer
Designing and building an easy-to use blockchain explorer which provides in-depth access into the underlying operations of the blockchain network is a challenging task. QAN Private Blockchain ships LibreScan as its official explorer.
Default operation model
By default the QAN Private Blockchain is configured in volatile mode. This means that you can freely experiment with anything as the underlying filesystem is memory (RAM) backed, so each time you want to start fresh, just reboot the VM and you will start from block zero!
CAUTION: Do not use the default operation model for production workloads, it is meant for development purposes. To persist data, distribute across multiple physical machines, increase node count etc. plese refer to the next section.
Customizing the operation model
Already have a use-case you wish to accomplish using QANplatform? Great! Here are the steps how you can customize the operation model for various use-cases:
Scaling with containerized architecture
As per the aforementioned public GitHub repository of QANplatform, the docker-compose.ymlfile reveals how much focus we put into containerizing the application in a scalable and easy-to-configure way.
This means that one can easily add more nodes either on the same physical host as VMs, or on different physical machines for power and network redundancy.
Adding persistent storage
Apart from that, one certainly wants to persist data instead of running in volatile memory as per the default development mode, for that these official guidelines are available from the known Virtualization providers:
Windows
macOS:
Linux:
After the required virtual hardware was added, the persistent volumes used by the containers should be mapped in the manifest file(s) to point to those disks.
Last updated
