Thread by @jadler0

What Avalanche is Not, Episode 1

This is the first in a series of tweet threads that will discuss fundamental shortcomings or pitfalls of the Avalanche Consensus protocol, and its instantiation in Avalanche. On today’s episode: fees.

Now that the Avalanche mainnet has launched, “we have a secret plan that will fix this issue and we won’t tell you until mainnet” is no longer an excuse. So let’s dig in and find out which issues were actually unfixed, and more interestingly, unfixable.

https://twitter.com/avalancheavax/status/1308251665359929346

You may have seen comparison tables like this one being circulated. But remember that when it comes to decentralized protocols, there’s always a catch. There is no free lunch and there are always trade-offs. We’ll find out in these threads what those are.

https://twitter.com/jadler0/status/1288173908936601601

First, some disambiguations:
- Avalanche Consensus (AC): a novel leaderless consensus protocol that uses random subsampling
- Avalanche: a DLT (haven’t heard that expression in a while!) platform launched by Ava Labs @avalancheavax, uses AC
- : the native coin of Avalanche

Avalanche consists of 3 chains operating under a single validator set: the P-Chain (platform) that manages the validator set, the X-Chain (transfers) that handles transfers with a DAG, and the C-Chain (contracts) that handles EVM contracts. Today we’ll examine the X-Chain.

The X-Chain uses AC and a DAG. This means anyone, at any time (leaderless, remember!) can add a vertex to the DAG. Each vertex consists of one (technically, zero, but that’s an implementation detail) or more transactions. Think of each vertex like a block.

Each vertex depends on its ancestors, but not on branches in the DAG that do not contain ancestors. This means that a partial order can be applied over the vertices (and thus, the transactions), rather than the usual total order provided by blockchains.

Now, if UTXOs are used, using a DAG in this way means that many vertices can be added to the DAG asynchronously, without having to wait for a leader to assemble one block at a time and propagate it across the whole network. Amazing! Where’s the catch?

Without a leader constrained by block _time_ (remember that Nakamoto and classical consensus protocols only emit one block every period of time in expectation), anyone could spam the DAG with so many transactions that it becomes intractable to validate them all.

How do we solve this spam problem? Optional transaction fees don’t work, since they’re optional. Required transaction fees also don’t work, because there’s no leader to send the fee to (+ side-channel refunds). **The only way to solve this is: required non-zero burned fees**.

So, how does the Avalanche X-Chain implement this? About 24 hours prior to the Avalanche mainnet launch, fees were publicly explicitly revealed in this PR:

github.com/ava-labs/avala…

The fee schedule is here. Huh, why is the fee fixed? It should at least be proportional to transaction size (but that’s an implementation detail). The real key here is that---unlike every single blockchain that isn’t an outright scam---*it’s not set by a block space market*. Why?

In a normal blockchain, fees are set by the market based on the transaction rate: the more transactions per unit time, the scarcer the block space and the more expensive each transaction becomes, and vice versa. In the X-Chain, fees are not related to transaction rate at all.

It turns out this wasn’t a willing choice made by the Avalanche developers, but rather it was _the only_ way to burn fees, which are required to prevent spam.

You can’t have a market based on the transaction rate without a reliable concept of time. The X-Chain operates asynchronously, so there’s no concept of time, and indeed there _cannot_ be a concept of time so long as the protocol allows anyone to add a vertex at any time.

There we have it. One of the (many) trade-offs Avalanche makes is having fixed fees, not by choice but by necessity. There are many such fundamental shortcomings of the protocol that are impossible to resolve, and I’ll be covering them in subsequent threads.