Throughput Scaling on Althea L1

In my last blog I talked about Althea L1 and the Althea Protocol . In this post we will discuss transaction throughput, focusing on Althea L1's real capacity requirements needed to facilitate iFi (Infrastructure Finance) at scale.

This topic is covered more concisely in the Althea whitepaper, but I wanted to take the opportunity to talk about the Althea L1 scaling philosophy and detail how it provides similar scaling performance as ZKP (zero knowledge proof) rollup based solutions while also being better suited to the iFi use case.

The ZKP tradeoff space

First, some ZKP context. For programmable transactions such as DeFi, ZKP (zero knowledge proof) technology provides an attractive scaling option, because programmable transactions can be difficult to execute and require significant permanent storage. A ZK proof of the same transaction has a fixed size and a fixed cost to verify which is significantly smaller than the average transaction, much less the largest transactions.

The downside is that computing the ZK proofs takes time, and the storage requirement is not so much reduced as it is moved around. Someone still has to store the original transaction information to understand what the ZKP validates.

I think this is a really undertold point around ZKP scalability. State growth, not immediate throughput, is the real problem that ZKP ‘solves’.

For Ethereum, every validator currently stores every transaction. Ethereum could easily operate with dramatically larger blocks with moderate impact to centralization, but over time the storage size increase would become fatal. As long as the state growth of a blockchain occurs at the same rate digital storage costs decrease, the cost of operating the chain stays the same. Once a blockchain has state growth that occurs faster than technological advancement in storage, the cost to operate will eventually become insurmountable.

Using a ZKP rollup strategy it is easy to ensure that the state growth of the L1 is very low. So low, in fact, that operating the chain would become cheaper and cheaper over time. Even better, since ‘rollups’ roll many transactions into a single ZKP state, growth on the roll-up chain is completely decoupled from the number and complexity of transactions. 

But now we come back to the inconvenient details: in this new ZKP paradigm the storage has to go somewhere. Transactions are no longer being stored by every validator, they now only store proofs. Now the user, or more likely some data availability layer, must store actual transaction data. Otherwise, the ZKP stored on the chain can be verified, but don’t provide any info about what has actually happened to your wallet in the past, or even your present value of tokens. The “Zero Knowledge" part of ZKP cuts both ways. Before ZKP, data could never be lost from an operational blockchain. So long as a new block could be produced, all data would be retained. But with ZKP rollips, the responsibility of retaining historical data has moved from everyone to a few parties, potentially even no one at all. Without a hard requirement to maintain historical data, chain history can be entirely lost over time.

This is where data availability layers come in as an answer to ?. These are conceptually similar to a Filecoin, except with the ZKP rollup chain itself as a sovereign customer. Node operators are then paid to store some subset of the chain state with some number of copies for redundancy.

A chain may choose to pay for only a year of state storage, leaving clients to pay for storing their own data themselves if they want more. Alternatively, the chain could trade indefinite storage availability for a better user experience at the cost of higher fees.From the perspective of a DeFi user, a ZKP rollup is not particularly lower cost, faster, or otherwise better to use. But from the perspective of the roll-up chain itself capacity is hugely increased.An apt comparison here may be with road expansion. Drivers are always convinced that one extra lane will reduce their commute times. But in reality the average commute time remains constant and the extra lane is consumed to support more people making the same commute in the same amount of time. The benefit of ZKP is ultimately not really user facing in the scaling sense. ZKP for privacy is a separate discussion.

The Althea L1 scaling design

CometBFT provides instant finality and decouples state growth from validation

The major theme in Althea L1’s design is the tension between programmable transactions and simple transfers for real world goods like bandwidth in the case of the Althea Protocol.

As discussed in the previous blog (link again here) DeFi transactions are much less sensitive to finality latency. If a DEX swap doesn’t finalize you don’t lose the input tokens for the trade. If a customer’s payment for a candy bar fails to finalize, they have already left with the product..

This makes the computational latency of a ZKP rollup much less attractive for Althea L1. iFi programs, specifically micro-transaction generating applications like the Althea Protocol, are limited by the latency of finality.No one wants to wait around several minutes for a prover to finish generating a proof of their candy bar purchase. Solutions to mitigate this latency in ZK would  involve a prover effectively promising to include your transaction in the next rollup proof.These promises do meet the speed and finality requirements for transfers of goods, but not the decentralized trust requirements. In order to generate a decentralized, guaranteed promise of inclusion at low latency you would effectively need a smaller blockchain just for returning inclusion promises.

In this case, Althea L1 replicates the most critical component of ZKP rollups for scalability, without sacrificing time to finality or trust. It does so through controlling state growth by allowing the chain to operate without the entire history.

Althea L1 uses CometBFT, a DPoS (Delegated Proof of Stake) consensus engine. A key concept of CometBFT is that in order for the chain to move forward, ⅔ of validator voting power must sign the next block. This means every block is instantly final, but comes with the consequence that it is relatively easy to halt a CometBFT-based chain. Compare this with alternatives likeETH2 consensus where the inactivity leak concept ensures that the chain automatically forks if finality fails.While the ETH2 solution may seem immediately more attractive, it’s this property of ETH2 consensus that really drives the need for keeping state growth on the main chain low. If it is possible for multiple forks to be valid, a node requires the entire history to determine which one to follow. 

For CometBFT chains, instant finality makes extremely compact proofs of chain state trivial. A proof must simply provide a history of validators entering and exiting the set (an infrequent operation in DPoS chains). Even for chains with a long history this proof is only a few kilobytes. The small size of these proofs is extremely important for bootstrapping light clients quickly and easily, a strong requirement for IoT, machine-to-machine payments,   and embedded applications. 

These compact light client proofs allow Althea L1 validators to operate without all historical blocks,opening up Althea L1 to utilize data availability layers in the same way a ZKP rollup chain would and meeting that same critical property where the minimum operational state grows more slowly than storage technology advances. 

Resolving transaction capacity

Now that the problem of storage growth is resolved, short-term throughput comes into focus as the next problem to tackle.While a ZKP rollup chain can process a theoretically infinite amount of transactions while moving around a fixed amount of data between the validators, Althea L1 validators still need to gossip about all constituent transactions.

We’ll discuss three solutions to this: first, a simple sanity check to evaluate the performance an ideal implementation should be able to achieve; second, load reduction strategies using payment channels; and finally, an exploration of Interchain Security, which is essentially Ethereum sharding made significantly easier by CometBFT’s instant finality and native IBC bridging.

Theoretical capacity of an ideal implementation

The minimum encoded size of an Althea L1 MicroTx is 137 bytes: 40 bytes for the addresses, 33 bytes for the signer's public key, and 64 bytes for signatures.

Assuming the limiting factor is bandwidth capacity between validators, and all validators have a  10Gbps connection, this gives a theoretical capacity of about 10 million MicroTx transactions per second. This estimate assumes that validators generate and agree on a 6.25GB block every 5 seconds.The current block creation and tx gossip code in CometBFT is nowhere near this efficient, but improvements over time will bring it closer to ideal theoretical capacity. 

It’s entirely possible that cheaply available server bandwidth will grow faster than the rate of block size increase. In the whitepaper we roughly estimate that 3 million TPS would be sufficient to cover all home internet users in the United States fully saturating a gigabit connection each.

Load reduction via payment size adjustments and using payment channels

Simple two party payment channels enshrined on chain with as a prioritized transaction type provide a viable solution here that not only increases capacity, but also reduces latency.Let’s use an Althea Protocol node as an example. As transaction throughput on the Althea L1 network becomes more congested with micro-transactions, the node can respond by reducing the frequency of its payments.

To do this, the node extends slightly more trust to the counterparty purchasing bandwidth, in exchange for paying fewer transaction fees. Specifically, it increases the settlement period—shifting from processing payments every few minutes to processing them every few hours.Since Althea L1 validators are incentivied to include MicroTx payments based on a fee percentage (link to whitepaper), rational actors will fill blocks with MicroTx payments in order of decreasing size and a client can simply observe the minimum fee included in the last block.Once this is no longer practical, the node can set up a two-party payment channel where funds are locked into the channel and the last channel signature can be submitted by either party to the chain at any time to pay out the channel balances.Presently, only an EVM implementation of payment channels is available, though translating this implementation to a native MicroTx module transaction can be done at any time chain capacity seems insufficient.

Combine these load reduction strategies with high bandwidth requirements for validator nodes and a very efficient gossip implementation and it starts to look eminently possible to serve the entire world's bandwidth needs with a single chain. 

Interchain Security

Using Interchain Security the main chain and its validator set effectively become a rollup chain, although one that uses CometBFT light client proofs instead of ZKP.

The sidechains would regularly post state proofs and cross sidechain transactions to the main Althea L1 chain. To ensure efficiency, blocks on the main chain would be kept extremely small, allowing payments made on the sidechain to finalize on the Althea L1 chain within just a few seconds.

Clients would be able to verify the inclusion of payments directed to them on any sidechain by maintaining only a light client for the main chain. As previously discussed, both the sidechains and the main chain could still leverage data availability services in this setup. This approach ensures that state growth on each individual sidechain remains highly manageable.

While the Interchain Security solution has all of the same scaling properties as a ZKP rollup it is significantly less power hungry, lower latency, and doesn’t require specialized hardware such as GPU or ASIC to settle quickly.

In general, we anticipate scaling optimizations, plus payment channels, will allow Althea L1 to operate at scale without having to add the complexity of an interchain security / sidechain design.

Hey, what about the EVM?

The MicroTx module was designed to be easy to scale, and transactions are a fixed small size. But what about the EVM?

While Althea L1’s MicroTx history can be safely discarded, the validators must have the entire EVM state in order to correctly compute the results of future EVM transactions.This is true, and part of why DeFi on Althea L1 is relatively expensive. The goal is to maintain EVM state growth at or below the level of storage media improvements and potentially implement a state sunset procedure.Sidechains could be used to design specific shards for EVM and DeFi operations, fees would then be slowly increased over time on each of these EVM shards to push users to a younger shard with lower fees. 

Conclusion

As someone with years of experience designing and building in the blockchain industry, this topic has been on my mind for quite a while—mainly because of its surprising conclusion. From a technical standpoint, blockchain scaling, at least for the capacity that Althea L1 might ever realistically need, is essentially a solved problem.

Moreso, it’s a solved problem without even having to reach for the most bleeding edge solutions. We have the luxury of tailoring the Althea L1 scaling design for lower latency and power usage by avoiding ZKP. 

This speaks to how much blockchain technology has improved over the last decade, and it also exemplifies an industry that has built superior technical solutions faster than it has secured wide adoption.

The Althea Protocol's design focus on implementing practical iFi, exemplifies an inflection point in blockchain technology, driving the utility and power of that technology to users and places where it was not before imagined

About Althea: Since 2018, Althea’s technology has brought blockchain-enabled internet access to thousands of homes and even the most challenging topographies. To read more, go to althea.net. 

To get involved, join Althea’s Discord: https://discord.gg/dT3sxP5gAw