Tl;Dr: The blog post demonstrates a misunderstanding of how to extend basic distributed primitives of voting-based protocols and make them viable for a production ready distributed ledger.

Let’s take a look at the first critique: “Snowball as is is not a ready-to-use binary consensus”.

The claim is that Snowball doesn’t reach consensus by itself as described. Let’s decouple that, and let’s do it using the simpler primitive, which is Snowflake. The primitive says the following: each node samples k nodes at random, and flips to whatever some supermajority of them vote for. Notice something important: this is the basic primitive that a classical protocol would use, but instead it would simply choose k (the sample size) to be equal to the entire network. If some supermajority (typically 67%) vote the same way, then a node will flip to that color. This means that:

Snowflake is actually a universal generalization of all voting-based (or quorum-based) protocols.

If you were to set k equal to the network size in Snowflake, then you just derived the basic quorum measuring primitive of all classical consensus protocols. Now, here’s the catch for classical protocols (which every other PoS system currently implements):

If there is no supermajority (quorum), the convergence time to that simple process is infinity.

Therefore, classical protocols must elect a leader or use some other process (maybe some really expensive VDF). Without such a mechanism, nodes could never reach the desired quorum even if there is zero Byzantine presence.

Instead, if you make k less than the network size, you suddenly introduce some errors. This is great, because we can use inherent bias in the sample to converge nodes towards some decision value.

Avalanche uses this basic idea to build the best-in-class protocol for scalability, and does so without using a leader. Naturally, since Avalanche is purposefully designed to not elect a leader (not needed, since it deals with communicative operations), in the theoretical model, it has a lower threshold of liveness because the adversary could always “undo” the natural bias in the sample. However, here’s the deal. First, this attack is practically unrealistic. It exists in a highly-theoretical model where the adversary has an instant view of the network at all times, and in practice this is very hard to achieve. Second, and much more importantly, if you want to augment Avalanche to the higher end theoretical limits of liveness, then the system designer can simply use any of the liveness mechanisms that classical protocols (including Eth2.0, Cosmos, etc). This is the part that the author of the critiques seems to have entirely missed. Likely not consciously, but due to lack of understanding.

Employing a leader or a VDF, however, is obviously not needed as the main DAG which is employed in AVA doesn’t need to operate on total ordering. If any transactions are conflicting and can’t make progress, they are issued by Byzantine nodes in the first place. Other subnets in AVA that need total ordering (such as the AVA smart contracts chain), employ the same liveness inducing mechanisms as some of the other latest PoS protocols, so liveness, like scalability in Avalanche, is optimal too.

The second critique is: “Some crypto-economic incentive is required to encourage people to post transactions that actually build the DAG.”

I’ll keep this one very short: every mechanism that any PoS ledger can use to incentivize nodes to validate transactions can be fit for Avalanche as well. The author seems to have little ability to isomorphically map incentives across commutative and linear chain data structures. We’ll leave the author to browse through the AVA codebase for more info.