Join 48,265 users and earn money for participation

The fundamental technical challenge with Avalanche, and how it hinders on-chain scaling

0 3 boost
Avatar for noise
Written by   299
8 months ago

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.

1
$ 0.00
+ $ 117.28 in other submissions
Avatar for noise
Written by   299
8 months ago
Enjoyed this article?  Earn Bitcoin Cash by sharing it! Explain
...and you will also help the author collect more tips.

Comments

nice FUD again.

$ 0.00
8 months ago

Its a nice article. I like your articles.I hope you will give more articles.and i like this article also.

$ 0.00
8 months ago

I think "But if we don't run it for a transaction which is double-spent" should be "But if we only run it for a transaction which is double-spent"

$ 1.00
8 months ago

You're right, thank you.

$ 0.00
8 months ago

I've seen critics about Storm on r/btc. Is there any Storm implementation being tested, or is it just theory yet?

$ 0.00
8 months ago

Nice article regsrding avalance. Thank you for sharing such a usrful article. It realy wirth reading

$ 0.00
8 months ago

Also note that if all one wants is "help miners sync their mempools, which would make blocks propagate faster making the network support larger blocks.", it does not need to touch consensus at all and can be experimented at anyone's leisure.

$ 0.50
8 months ago

Avalanche takes and impotant aspect in blockchain... Thanks for the eyes opening. Either ways

$ 0.00
8 months ago