Apart from how to integrate Avalanche with Bitcoin Cash's consensus mechanism, there is another difficult problem we face when integrating Avalanche. The problem boils to down to this simple question:
Will Avalanche run directly for every transaction?
If the answer is yes, then it will hinder our prospects to scale on-chain. But if the answer is no, then it will cripple it's effectiveness in preventing 0-conf double spends.
But I thought Avalanche would help us scale?
Yes, Avalanche will help us scale in one aspect. Avalanche will help miners sync their mempools, which would make blocks propagate faster making the network support larger blocks.
But scaling isn't a single monolithic thing. There are many aspects we need to consider when increasing on-chain capacity besides block propagation. With Avalanche the bandwidth usage for nodes will go up. So instead of nodes being busy sharing transactions and block information, they will also have to bounce Avalanche messages between each other, which reduces the space for transaction data.
This also opens up a large DDOS vector, where an attacker could easily flood the network to overload nodes and to crowd out crucial transaction and block propagation.
Coins with zero-fee transactions face a similar problem, and the only solutions we've seen so far have been to centralize the network or half-assed anti-spam policies that are easily worked around. It's a very difficult problem to solve in a permissionless network.
What if we only run Avalanche when we notice a double-spend?
The obvious solution is to only run Avalanche when we notice a double-spend, or to shut it down when we face a spam attack.
But this makes Avalanche pretty useless in preventing 0-conf. To see why let's examine the different types of 0-conf, which I discussed in a previous post.
When Avalanche is run for all transactions, it does prevent 0-conf in many cases:
Fast double-spends
Avalanche does not improve over double-spend proofs
Delayed double-spends
Avalanche helps
Miner assisted double-spends
Avalanche helps
To see why this is so, please read the previous post.
But if we only run it for a transaction which is double-spent, then Avalanche does not help:
Fast double-spends
Avalanche does not improve over double-spend proofs
Delayed double-spends
Avalanche does nothing
Miner assisted double-spends
Avalanche does nothing
The reason Avalanche does so poorly here is that it hasn't decided anything about the transaction before it's too late.
In the case of a delayed double-spend, Avalanche would only kick in after the scammer has left the store.
With a miner assisted double-spend the double-spend is only seen in the block for the first time. While in theory Avalanche could be used to orphan that block... It seems highly unlikely that it would be implemented that way as the risk-averse miners would want to accept it.
So we can conclude that Avalanche must be run directly, otherwise it's useless, but this hurts our scaling prospects. We're stuck between a rock and a hard place.
Is there an alternative?
There's no ready solution, but there are some good proposals out there. For example:
0-conf forfeits is an excellent proposal that could reduce the risk of any 0-conf double-spend, but it comes at a severe user experience cost.
Storm reduces the risk for delayed double-spends and miner assisted double-spends, without a radically increasing the network's bandwidth usage and it builds on, instead of replaces, the tried and tested consensus mechanism on Bitcoin.
nice FUD again.