Avalanche: The pros and cons of the super fast and innovative cryptocurrency
An in-depth look at the advantages and disadvantages of Avalanche compared to other cryptocurrencies
Avalanche is fast. It’s super fast. It’s also scalable, decentralised and secure. If you read the marketing it’s perfect. However everything comes with costs. What are Avalanches? In this post I’ll go over both the advantages and disadvantages of Avalanche
Advantages
Speed
With average block times being around 2 seconds, Avalanche is one of the fastest cryptocurrencies out there. Solana has 400ms block times but blocks don’t reach finality for another 5-12 seconds which makes the consistent 2 second finality from Avalanche very impressive.
Innovative
In general there are two models that cryptocurrencies build their consensus methods around. Longest chain wins models which Bitcoin first introduced. Or BFT based models which were the classic consensus methods that have been adapted for cryptocurrencies. Avalanche uses neither and developed its own novel consensus method based around nodes continuously polling small random subsamples of the network to try and gauge what the consensus opinion is.
If you interested in how it works in more detail I have a video explaining it here:
Limited supply and fee burning
Avalanche has a max supply of 720 million AVAX tokens which should be hit around 2030. It also has a fee burning mechanic like Ethereum. This gives it great tokenomics for potentially being a store of value once the initial distribution of tokens is over.
Supports re-staking through subnets
Subnets are sidechains to the main Avalanche ecosystem that are run by a subset of the Avalanche validators. If a validator also runs a subnet, the subnet will provide that validator with a reward.
This gives Avalanche validators another potential source of revenue which reduces the reliance on Avalanche to provide the incentive for running a validator itself. This will help Avalanche maintain people running validators even if the max supply of AVAX tokens has been reached and they are no longer giving staking rewards.
Flexible
Most cryptocurrencies consist of a single chain which has one operating environment. Avalanche is made up of 3 chains. The X-chain is a high throughput chain but only supports basic transactions, the C-chain is the smart contract chain that supports the Ethereum Virtual Machine so users can build the same smart contracts as Ethereum but it has low throughput and the P-chain is there to keep track of users staking and subnets.
Whilst it’s unlikely that there will be more chains within the main ecosystem in the future, the flexibility is there to add another chain with a different smart contract language if needed.
However whilst these are big advantages over other cryptocurrencies, nothing is perfect. Here are the disadvantages:
Disadvantages
Not robust
In a lot of the marketing you see that Avalanche is just as robust as longest chain wins models whilst having the speed of classic models. In reality Avalanche requires 80% of the stake to reach consensus on a block to maintain liveness. This makes it one of the least robust cryptocurrencies.
Not that scalable
If you read the marketing you would think Avalanche would be able to handle 100x the throughput that Ethereum does. In reality it looks like the C-chain can do around 60tps.
Seeing as Avalanche doesn’t have as big of a state size as Ethereum, this performance would be expected even if they just copy and pasted Ethereum without changing any of the code.
Avalanche consensus is able to provide extremely fast confirmation times but this doesn’t translate into being scalable.
Unable to implement slashing
Slashing is a method where some proof of stake based protocols will punish validators who clearly break the protocols rules by slashing the funds they have locked up. This brings extra security as it provides a disincentive to misbehaving.
Due to how it is normal behaviour for validators to switch their opinions in the consensus method, it is not possible for Avalanche to implement slashing as they can’t differentiate between normal and malicious validators.
Scaling through Subnets
Subnets are sidechains to the main Avalanche ecosystem that are run by a subset of the Avalanche validators. They are the main method in which Avalanche aims to scale. The problem with subnets is they only inherit a subset of Avalanches security so aren’t really scaling.
Ideally you will have the majority of validators running a subnet in order to have a high level of security, but validators only have limited bandwidth and already have to run the 3 main Avalanche chains so they only have limited capacity to run subnets. This means you can potentially get maybe 1 or 2 high security subnets that are run by the majority of validators and then all other subnets will be low security and only be run by a small subset.
If there are only a few validators running a subnet they won’t be secure at all. There is no slashing in Avalanche so the subset of validators can do what they like in the subnet and get away with it with no punishment. If there are only a few validators, collusion becomes likely.
Subnets seem like they can be a good option for middleware services like bridges or oracles but seem like a bad option for general scaling. The point of scaling is to scale whilst keeping security. Otherwise why not just create a bridge to a centralised high performance database and have super high scalability.
Complex to self verify
With normal consensus methods, if you are running a normal node you can easily verify consensus by just looking at either the proof of work hash or the validators signatures in the block header. This is very simple and allows for an arbitrary number of nodes to verify consensus with no additional load on miners or validators.
Avalanche on the other hand requires normal nodes to go through the same subsampling process as validators to figure out which blocks there is consensus on. This means they need to have a direct connection with every validator in the network so they can poll them.
Limited number of nodes
Due to nodes requiring a connection to all validators but validators only have a limited number of connections they can open, it means there is a limit to the number of normal nodes that Avalanche can support
This limit is probably quite large so not a problem in the short term but there are no sybil protections on setting up a node so an attacker can create millions of nodes and overload validators with connections and subsampling requests to potentially block any new nodes joining the network.
Validators control the network
In a normal cryptocurrency like Bitcoin or Ethereum, nodes are seen as the most powerful entities of the cryptocurrency. Yes miners/validators have a lot of power but ultimately nodes are in control as shown by the bitcoin fork wars from 2017 where the majority of miners did not want to do the segwit upgrade but nodes ended up forcing the upgrade on them.
With Avalanche, the validators have far more power. Nodes can’t even verify consensus without the validators cooperation and nodes don’t even have access to the mempool so have no idea if any transactions are being censored.
Poor distribution
If you remove the 50% tokens put aside for staking rewards, the team + foundation got 38.6% of the token supply. This seems excessive. Only 18% actually went to a public sale.
Newer tokens are always going to have a worse distribution than older tokens so this is something that can get better over time though.
Predictable randomness
Other protocols spend years of research trying to find a way to produce an unpredictable form of randomness that all nodes in the network can agree on so no one can try to game the randomness and have an unfair advantage at trying to become the block leader.
Avalanche simply uses a predictable sampling function to pick a random validator from a list. It is possible to simulate it and add a validator that will win the next block.
The reason this isn’t that big of an issue is because you need 2000 AVAX to set up a validator and it has to be locked up for a minimum of 14 days. This makes attacks economically unviable. It’s not ideal but shouldn’t lead to any big problems
Dishonest marketing
All marketing exaggerates things here and there. It’s expected. Avalanche goes a bit overboard though. They have taken words that are already used for one thing and decide they want to use the same word in a different way. For example when they built a trustless bridge where you had to trust a few people with access to a multi-signature or when they said subnets had shared security like rollups but only have a subset of the security.
It makes it very hard to trust the claims that come from the Avalanche foundation.
Conclusion
Overall whilst Avalanche is incredibly fast, it has sacrificed a lot to achieve that.
It’s not robust, requiring 80% of the stake to be online. It sacrifices decentralisation as normal nodes can’t verify consensus as easily. It’s not particularly scalable and their main scalability solution of subnets sacrifice security.
They used to be somewhat unique by having a leaderless DAG based chain but this was changed into a blockchain and is now leader based.
Now it’s hard to see what the selling point of Avalanche is anymore. It’s just a faster but less secure, less robust and less decentralised version of Ethereum. Previously it had taken a top spot in the market of being where users went to get access to a cheaper EVM chain but now that EVM based rollups like Arbitrum have started to build up their ecosystems, it’s hard to see what Avalanche will offer.
If you enjoyed this post, I’m planning to create posts like this for all the major layer 1 cryptocurrencies so subscribe if you don’t want to miss them.
I also have a YouTube channel, where I create educational content about cryptocurrencies, if you are interested.
Thank you for writing these reports on each project in the cryptocurrency space. I've found them very useful. You're the only writer I've found that takes an informed approach to analyzing the drawbacks of each project and puts everything in the broader market context.