Background

As of January 2024, 5.3 billion people (or 66% of the world) use a device connected to the internet. The ways in which bandwidth is sold, purchased, and consumed have far-reaching implications, making it a topic of significant interest.

The Althea routing and billing protocol (“the Althea Protocol”) allows anyone to install equipment, participate in the decentralized ISP, and receive payment for their service.

This transforms bandwidth from a good that can only be sold in exclusive contracts into a commodity that anyone can purchase dynamically from anyone else. Further, the Althea Protocol is cheaper to use because:

  • Nodes dynamically switch between connectivity providers to find a route with the best combination of bandwidth and low cost.

  • Overhead costs, like advertising and marketing, are reduced as the only advertisements in this system are the automatic advertisements of price and route quality between nodes. The open-access nature of this system makes it easy for new entrants to participate efficiently.

  • Contract and billing costs are eliminated by dynamically routed micropayment, which enables devices to automatically pay each other efficiently.

Althea is the technology that makes this all possible.

Althea L1 Overview

Althea L1 is a micropayment specialized blockchain network designed to meet the requirements of the Althea Protocol operating at scale. Specifically, it is intended for:

  • Fast finality As soon as a transaction is accepted into the blockchain, it cannot be reverted.
  • Low costs to settle payments Payments on the order of a few cents must be practical.
  • Micropayment priority Payments must be accepted in a predictable manner at all times.
  • Efficient light client verification It must be possible to verify payments quickly with low overhead on embedded devices.
  • Integrated EVM Arbitrary computation offers valuable flexibility in designing supplemental contracts and tokens, allowing for applications that support the micro-payment settlement platform while maintaining its core function.

This unique blend of properties allows the Althea Protocol to achieve scalability, reliability, and longevity—crucial elements for any successful internet service platform.

The Althea Protocol

Althea allows routers to meter and pay each other for bandwidth using blockchain micropayments. An important architectural detail is that nodes only pay neighbors for forwarding packets. This allows us to phrase the route price as a routing metric in a distance vector routing protocol such as BGP or Babel (Chapin & Kunzinger, 2006) (Chrobozek & Schinazi, 2021).

On top of this pay-for-forward network, we build a system where consumers can pay for internet access. The Althea Protocol is intended for use in local “mesh” networks (Frangoudis et al., 2011).

Network Overview

To simplify the explanation of Althea’s network architecture, we present several ‘roles’ that devices may perform. Note that these are logical roles, not physical ones. So, a single device may perform several or even all of these roles simultaneously:

  • User nodes are installed by individuals seeking internet access through Althea. These nodes function similarly to traditional ISP-provided routers/modems but with a critical difference: they operate independently of any single ISP. User nodes connect everyday devices to the Althea network, handle payments, and provide standard networking services like WiFi and LAN connections.

  • Intermediary nodes are installed by connectivity providers seeking to earn income by forwarding internet traffic. These will often be more powerful and placed strategically with good line of sight to other nodes. Notably, most nodes function as both intermediary and user nodes since the same software allows for buying/selling bandwidth and relaying traffic. A well-placed home router can carry substantial traffic and generate revenue.

  • Gateway nodes are specialized intermediary nodes that directly connect the Althea network to the wider internet via low-cost sources like internet exchanges or business-grade connections from a conventional ISP. They bridge Althea’s physical network to the outside world, while exit nodes operate the link to the wider internet.

  • Exit nodes, potentially hosted in data centers reachable over the internet, are connected to gateway nodes via VPN tunnels. They serve two essential purposes: first, measuring network quality to enable optimal gateway node selection, and second, handling the legal responsibilities of an ISP (like address translation and copyright matters). This frees gateway nodes to focus solely on bandwidth provision without monitoring user traffic.

Routing

The Althea routing protocol uses well established routing protocols (Babel) used by traditional ISPs as its base. This technology checks each router along a particular route for service quality and provides a composite score to be compared to other potential routes. Thus, Althea is able to route its service through the routers offering the best quality of service for the end user. Babel was selected because it has several valuable properties we can use. However, any distance vector routing protocol could be modified to exhibit the properties Althea requires. Distance vector protocols are already used extensively on the internet, with Border Gateway Protocol (BGP) being one of the most well-known ones.

Routing in distance vector protocols is based on an advertised connection quality metric. Nodes send an announcement packet stating their identity and existence to the network once every predetermined period. These announcement packets are then passed from node to node. Each node updates the metric to reflect the connection quality between it and the neighbor where it got the announcement. Using this information, each node can build up a routing table of the best neighbors to forward packets to reach any network destination in O(n) time on each node.

We have also added a verifiable quality metric and a price metric to the existing distance vector routing.

A verifiable quality metric is a connection quality metric that can be verified by a node and the destination where it is sending packets. Our first extension to Babel allows nodes to verify the metrics advertised by their neighbors.

To advertise prices, a second metric is added to the routing advertisements, this time containing a “price” value for some arbitrary but agreed-upon amount of data transfer. When passing advertisements, each node updates the price field with its fee for passing data. Routes are then selected by optimizing the quality metric vs. the price metric and paying the selected total sum required to route all the way to the destination.

These two extended metrics have the net effect of “unbundling” the traditional metric field in Babel, a simple unsigned sixteen-bit integer each router adds to based on their own determinations of packet loss and optionally latency. This enables independent decision-making across the network, transparent pricing, and objective quality validation.

Payments

Each node on the network establishes an internal account for each of its neighbors. Bandwidth is then metered, tracked and used by each node to independently compute what it is owed and what it owes each neighbor. A network-wide threshold is set at which payment is expected.

For example, each node would expect to be paid after a specific monetary value of bandwidth was used. Example values could include 1c or 50c, but all network nodes must agree on this value.

If a payment is expected but not delivered at any given time, the unpaid node will throttle or entirely cut off connectivity.

Micropayments create a low-risk environment for both buyers and sellers. For buyers, the risk is minimal: they might prepay a neighbor node for bandwidth that becomes unavailable. Likewise, sellers might provide bandwidth to a node unable to pay, potentially missing out on other customers. However, the small payment amounts keep potential losses insignificant for both sides.

Despite using micropayments, trust is still a factor. We have chosen a “pay after” model to minimize risk. In a “pay before” system, malicious nodes could repeatedly profit by taking payment without providing service. With “pay after,” however, those refusing payment gain nothing but a bad connection, making exploitation pointless.

Each node also pays an exit node to forward traffic from the internet to them. This is how “download” traffic is paid for in a pay-for-forward network.

For the purposes of the Althea Protocol, any unit of account can be used for payments. Potentially, multiple currencies could even be used within the same network simultaneously. Nevertheless, in general, stablecoins will be used and agreed upon as the payment currency by a network running the Althea Protocol.