QANplatform

We thank the QAN team for their cooperation during this security assessment of the QAN Virtual Machine (QVM) execution pipeline.

QAN aims to provide a quantum-resistant Layer-1 blockchain supporting versatile smart contract development. Central to this is the QVM, designed for secure and deterministic execution across multiple programming languages. The audited workflow involves processing contract source code through a precompiler (creating a verifiable PEM format), a language-specific compiler (producing an ELF binary), and then execution of the smart contract.

Execution occurs within QEMU (initially within gokvm). Inside the VM, the Hermit engine ensures deterministic execution by intercepting the contract binary's system calls, managing scheduling, and controlling environmental factors. This layered approach seeks to deliver a robust, flexible, and verifiably consistent runtime for QAN smart contracts.

QVM module was audited at this scope as a standalone module instead of being operated in a blockchain environment. More than 2821 unique test cases were evaluated to discover potential sources of non-determinism which produced 22 findings. All of the reported issues were fixed by QANplatform team. The system users should acknowledge all the risks summed up in the risks section of the report.

{FindingsVulnSeverityStatusTable}

Documentation quality

• Mix of basic internal documentation and inherited docs from third-party components.

• Some high-level information published on the official QANplatform website.

• Understanding detailed interactions often requires reading code and scripts directly.

• Documentation lags behind recent features and technical decisions.

Code quality

• Multi-language codebase: primarily Go (build tools) and Rust (Hermit), with C/C++ (SDKs).

• Extensive use of shell scripts and Dockerfiles for build orchestration.

• Significant code duplication observed, especially across Dockerfiles for compilers/precompilers.

• Demonstrates a modular structure separating key components (VMM, Compiler, Hermit).

• Test coverage is limited, focusing on basic functionality.

Architecture quality

• Project employs a modular design, separating VMM (QEMU, initially gokvm), compiler orchestration (qvm-compiler), deterministic execution (Hermit), and language-specific build components.

• Utilizes QEMU virtualization.

• Relies on the Hermit engine within the guest VM to enforce deterministic execution via syscall interception and controlled scheduling.

• Features multi-language contract support as a core architectural goal, achieved through containerized compiler environments.

• Host-guest communication for state interaction is dependent on a gRPC protocol over VirtIO networking.

• Scalability model uses a VM pool; actual throughput constrained by host resources, VM lifecycle overhead, gRPC latency, and Hermit's performance impact.

• The build pipeline (Precompiler/Compiler) currently runs outside the deterministic Hermit environment, creating a potential source of non-determinism in the overall process.

• The multi-layered approach (virtualization, custom OS, deterministic overlay, build tools) contributes to significant overall system complexity.

The QAN Virtual Machine (QVM) is a sophisticated execution environment engineered to operate smart contracts on the QAN blockchain platform. Its primary objective is to provide a secure, isolated, and multi-language compatible runtime that guarantees deterministic execution. Determinism is paramount in blockchain systems, ensuring that every validating node reaches the exact same state transition when processing the same transaction, regardless of the underlying hardware or timing variations. QVM achieves this through a multi-layered architecture involving specialized build tooling, KVM-based virtualization, and a dedicated deterministic execution engine.

The lifecycle of a smart contract within the QVM ecosystem begins with a flexible build pipeline designed to accommodate a wide array of programming languages. First stage involves the Precompiler. This tool processes the original source code, applying language-specific minification and compression techniques (like Brotli). The output is a standardized PEM-encoded file containing the processed source, versioning information for the precompiler used, and a cryptographic hash (Keccak256) of the contents. This PEM format serves both for potential storage efficiency and as a verifiable artifact, allowing anyone to confirm that a given PEM file corresponds to a specific original source code by re-running the same precompiler version.

Following precompilation (or directly from the original source), the code enters the Compiler stage. This infrastructure is centered around the qvm-compiler Go application, which acts as an orchestrator. Based on the input source file extension or explicit flags, qvm-compiler identifies the language and invokes the corresponding language-specific compilation logic. Each supported language (e.g., Go, C++, Rust, Java, Python, JavaScript, etc.) has a dedicated Docker-based build environment. These environments contain the necessary toolchains (like tinygo, clang, rustc, javac), specific runtimes or interpreters where needed (like minijvm, gpython, QuickJS), and common build tools provided by a base buildtools image. A critical component included during compilation is the qan_proxy library, which provides the standardized interface for the compiled contract to interact with the blockchain environment (e.g., reading/writing state, initiating transactions). The ultimate output of the Compiler stage is a standard, self-contained ELF executable binary, ready for execution within the QVM.

The core runtime is provided by using QEMU-based virtualization. Initially, during the audit the project was using gokvm instead of QEMU-based hypervisor. When a contract execution is requested, QVM (QAN virtual machine) selects an idle VM and initiates the process. Each VM boots a highly customized, minimal Linux kernel, specifically patched to remove sources of non-determinism (like standard time sources or unseeded randomness). The VM's root filesystem is an initial RAM disk (initrd) containing the essential components for contract execution. This includes an /init process acting as a guest agent, essential libraries, a gRPC proxy for host communication, and crucially, the 3rd party execution sandbox component binary.. Communication between the host and the guest VM primarily occurs over virtual network connection using a gRPC protocol, facilitating the transfer of the contract binary, input data, environment variables (blockchain context), and handling interactive calls during execution.

Within the carefully controlled guest VM environment, the Hermit engine provides the final and most critical layer for ensuring determinism. The guest agent invokes Hermit to run the compiled ELF contract binary. Hermit acts as a deterministic process supervisor, intercepting all system calls made by the contract. It controls the execution flow, manages process/thread scheduling deterministically, replaces standard time and randomness system calls with deterministic implementations seeded by blockchain data (e.g., block hash, timestamp), and ensures that interactions with the virtual environment are perfectly reproducible. Any calls the contract makes to interact with the blockchain state (via the linked qan_proxy library) are translated into gRPC requests, passed through Hermit, the guest agent, VM, and finally handled by the host blockchain node, with results returned along the same path.

Upon completion, Hermit captures the contract's exit code, standard output, and standard error streams. These results are packaged and sent back to the host gokvm via the gRPC channel. The VM then returns the final execution result to the blockchain's core logic. This comprehensive, layered approach allows QVM to securely execute diverse smart contracts while guaranteeing the deterministic outcome required for blockchain consensus.

The scope of the project includes the following components from the provided repository:

Components in Scope

A primary scope of the audit is to determine if the QVM runtime can be abused to cause non-deterministic output given any output binary from any of the supplied compilers and an arbitrarily chosen state.

The main scope of compiler and pre-compiler pentesting is assessing if there are situations in which:

• The supplied pre-compilers produce non-deterministic output from the same source code.

• The supplied compilers can produce non-deterministic output binaries given any output from the language-relevant pre-compiler.

Assumptions:

• Input is valid source code for the given programming language that the pre-compiler intended to handle.

• Compilers are only fed the output of the pre-compilers as their input.

• QVM runtime is only fed the output of the compilers as its input.