Appliance Exits for Althea

The Althea Whitepaper 2.0 introduced several enhancements to the original Althea protocol, expanding its capabilities while maintaining its core design principles:

• Althea L1: A layer 1 protocol designed for machine-to-machine payments
• Liquid Infrastructure: A native feature of Althea L1 that bridges the gap between RWA and DeFi
• Improved appliance exit architecture

Though the core feature set has grown and new functionalities added, the foundational design of the Althea Protocol has remained remarkably consistent since the original whitepaper seven years ago and the first operational prototype five years ago. 

This stability is a testament to the strength and foresight of our initial design.

A recent upgrade to appliance exits marks the most notable refinement in how Althea Networks operate, aligning even more closely with real-world operator needs.

Right now Althea networks are structured like this: 

Gateways provide an internet bridge that pulls nodes not physically connected to the network into the local network, where clients can talk to them. The Althea Whitepaper 2.0 provides further details on gateways and the network structure.

Bootstrapping Trust

Bandwidth flows like water in an Althea network. It automatically traverses the path of lowest cost and highest quality, shifting constantly to find the sweet spot for the user, balancing cost, throughput and latency.. Your home internet traffic could take any route, even several different routes, through the network throughout the day.

Privacy is of course an essential consideration for any network, as no one should rely on a network that allows others to snoop on their internet activity. All traffic on an Althea network, from source to exit node, is encrypted using Wireguard and all Althea routers come pre-programmed with the public encryption key of an exit node to avoid man-in-the-middle attacks.

While this approach to routing and security is excellent from a technical perspective, it has an unintended effect on network operator behavior, who are more inclined to use exit nodes that are already programmed into the firmware.

Although it is fairly straightforward to add a new or additional exit node to a router—and takes less than a minute to do—in practice no operator to date has elected to do this at scale. Anything beyond the absolute minimum amount of configuration per user is a burden best avoided. For this reason, operators routinely request that their exit node details are added to the default build of the firmware.

This isn’t ideal, both because building a new version of the firmware takes time, but also because it simply doesn’t scale operationally. An ever longer list of exits to select just increases the chance of error during setup.

Far, Far Away

While deploying an exit server with simple automation is not particularly complex, in practice we find that network operators tend to put more focus on network management and less on server infrastructure, often relying on others to set up and maintain an exit at a strategically convenient location.This approach works well in well connected areas, but we have found that setting up an exit in more remote regions of Africa or South America can be a bit more challenging.

If a network relies on exits that are too far away or hosted in cloud data centers, network performance can be significantly impacted. Optimizing exit placement becomes crucial, and tolerating a sub-optimally configured network is simply not viable.

Until now a pre-configured exit was typically shipped, or a system administrator would remotely configure one for a given deployment, but these are added steps that hinder the speed and ease of network deployment.

Compare this with the steps involved to setup a typical Althea router:

1) Add firmware (using the browser-based UI)

2) Explore Internet

The challenge therefore is to enable simple and optimized deployment to any new network, regardless of geography.

Appliance Exits, Bootstrapped by Althea L1

This brings us to our solution: appliance exits. With appliance exits, we areredefining what it means to run an Althea network. This innovation introduces a new type of Althea firmware—exit firmware—which transforms any compatible router, not just server hardware, into a fully functional exit.

For operators, this means seamless integration of the exit and gateway roles, allowing them to directly route and exit customer traffic without additional infrastructure.

This simplifies setup and operation, reduces hardware costs, and presents more options for customers, whose routers are free to roam to any other exit over the internet.

Gone are the days of shipping specialized servers for each deployment. Now, any off-the-shelf $30 WiFi router can be flashed as an exit in minutes.

Exit Database Smart Contract

In the traditional server-based exit model, each exit required a backend database (PostgreSQL) and an authentication method to verify users, such as an SMS API key or an email account.

For most users, this authentication step was the only time they even noticed they were connecting to an exit. Often, this was handled during installation, making it an invisible part of the Althea experience.

Because Althea clients can seamlessly roam between exits using a shared customer database, operators naturally gravitated toward a single, unified database. This ensured users could always switch to the best available exit without re-registering or any other additional steps.

To simplify this process, we designed a solution eliminating the need for individual exit registration. Instead of signing up for just one exit, users now instantly register for all possible exits.

Appliance exits leverage an exit database smart contract on Althea L1, serving as a decentralized user database. Clients register directly to the smart contract on the Althea L1 EVM, which allows any exit to serve any user simply by referring to the smart contract data. The exits themselves also register to the same smart contract, enabling clients to retrieve a list of available exits and seamlessly connect to the best one available.

This approach removes nearly all manual configuration from exit operations. Exit Appliance images can now simply start up and go—no extra setup required.

Solving Bootstrapping

Even with the exit database smart contract, bootstrapping is not entirely solved. Sure, once a client is online, they can simply query the smart contract and get a list of exits to trust, but they need to query this list before they can get online.To resolve this Catch-22, we mirrored the concept of https certificate chains and created root trust servers for Althea exits. 

Instead of being built with the exit public key, Althea router firmware is now built with a number of root keys. The root trust servers simply grab the latest copy of the exit database smart contract data off of the Althea L1 EVM, sign it, and pass this data onto an exit. The exits hold these signed copies of the exit server list from the exit database and provide them to Althea routers as they come online. From there, the router can verify the signature, get online, and query updated data for themselves.

CGNAT and SNAT

In addition to the new appliance design, we’ve bundled significant feature improvements into this release. This includes support for CGNAT and SNAT IP assignment modes.For a quick introduction to why this matters, start with Why 32 Bits Wasn’t Enough, and the concept of NAT (Network Address Translation).Exits can now use multiple external IPv4 addresses in tandem and assign users their exclusive static IPv4 address out of the pool while doing it. Even better, this can all be configured from the router dashboard like any other feature.This is a huge jump for exit operators in terms of ease of use. Before the appliance exits, there was no GUI of any kind and a new exit would need to be added for every 400 or so Althea users that were connected to it.

With this new feature improvement, there is no longer any practical limitation to the number of users connected to a single exit in terms of software, as long as sufficient IPv4 space is available.

Native IPv6 has been supported since Beta 20 and will also be possible to configure from the UI.

Conclusion

Althea has always been about helping people build systems that work for them. We are excited to apply five years of operational experience to design refinement, optimization and simplification: making it faster and easier for our network operators to building new networks, deploy new infrastructure, in new and more challenging places with more customers than ever before!

Coming up next week is a deep dive on *Liquid Infrastructure* and exactly how the account abstraction on Althea L1 is designed.