Architecture overview
Last updated
Last updated
The architecture of the Leea Protocol is built around principles of maximum security and usability.
The Controller is an operational unit serving multiple purposes:
Stores an inventory of nodes
Dispatches orders to agents
Manages the network peers list
Provides an API for the dashboard
Node controller manages a specific node, making it accessible within the network.
The Node controller is an application installed on a node and includes both hypervisor and transport functionalities. The hypervisor's role is to launch VMs and make them accessible through the Service VM.
The Service VM starts automatically after node setup, using a small allocation of resources to handle:
Network connectivity and dynamic routing
Firewalls
An external gateway to the network (if the node has a public IP)
DHCP
Validators are crucial for securing the protocol.
They store portions of encryption keys and validate VM integrity to prevent malicious nodes from accessing VM internals.
The image registry service provides access to community-created VM images, stores user VM drives, and encrypts them.
Users can create their own front-stores on top of the Leea Protocol using the External Marketplace API.
As shown in the diagram above, users need to generate a new registration key for the agent and create a configuration file on the node.
The configuration file is stored at $HOME/.leea/config with the following structure:
When the Leea Agent starts, it checks the configuration file, scans the node for available hardware, and gathers the node's specifications.
The agent validates the node on each startup to ensure data for the remote attestation process are up-to-date.
This process is designed so that even a malicious node cannot access any data inside the VM.
When a user submits an order, the API finds a suitable node and requests the Image Registry to create an encrypted image with the selected OS and an unencrypted initrd image for the VM.
The API sends the VM specifications and image URLs to the Leea Agent.
When the initrd image is loaded by the VM, it initiates the Remote Attestation process with Validators. Upon success, it fetches the decryption keys from them.
The OS on the decrypted disk is then allowed to boot normally, and post-provisioning tasks are executed automatically.
The Leea Agent detects that the VM is ready and sends a request to the API.
The API creates a GeoDNS record and closes the order.
VMs within the Leea Protocol can be accessed from the internet through gateways.
All nodes with public IPs act as gateways to the internal network. These IPs are stored in GeoDNS records, and a mesh topology of network ensures that users worldwide can access services hosted on any VM.
To access a service using any protocol that supports TLS SNI, the client (e.g., a browser) resolves the domain using GeoDNS to the nearest gateway IP address and connects to it. The gateway extracts the domain name from the TLS SNI hello packet, resolves it to an internal IP address, and then routes the connection to the target VM.
For protocols that don’t support TLS SNI, the internal IP address can be obtained through the API, after which the same process is followed.
Why don't you use IPv6? We do, but we aim to offer our services to all internet users, not only IPv6 enthusiasts.
How can I access a server on port XXX that uses a custom protocol? If the protocol supports TLS SNI, simply access it. If not, an SSH tunnel will be needed.
Do you decrypt traffic to get SNI? No, SNI is part of the TLS handshake and isn’t encrypted. We use it purely for routing purposes. All packets are delivered without modification.
The Leea Agent downloads the images and creates the VM according to the specifications. All VMs are created using AMD SEV or Intel TDX technologies, so the RAM is encrypted with keys accessible only to the processor. See for more information.
