John Adler | ✨⛽ Profile picture
Sep 26, 2020 15 tweets 4 min read Read on X
What Avalanche is Not, Episode 3

Last episode, we discussed rewards. On today's episode, the other half of the Nakamoto Incentive: penalties. We will show how Avalanche does not provide the accountable safety property that modern PoS protocols have.

The Nakamoto Incentive is both an incentive (rewards + fees) and a disincentive (penalties for both individuals and majorities). Both are necessary for permissionless consensus protocols to function without having to heavily rely on altruism.

Note that it is absolutely critical that incentives be in place. It is *not* sufficient to prove that a permissionless consensus protocol is live and safe under an honest majority. It must also be shown that the protocol incentivizes an honest majority.

The disincentive is made up of two components:
1. A penalty for a minority individual that misbehaves.
2. A penalty for a (colluding) majority that misbehaves.

We'll only cover the second in this episode. The first is left as an exercise for the reader.
In a permissionless consensus system, a majority of colluding Sybil resistance mechanism (stake, hashrate, etc.) can always re-org the ledger, i.e. un-finalize finalize blocks. This is why there must be a penalty in place if this ever happens; a disincentive.
In Nakamoto Consensus, the penalty can actually take on several forms:
1. decrease in coin price
2. decrease in hashing hardware value due to changing the hash function
3. decrease in hashing hardware value (this is actually either 1 or 2)
Note that regardless of which penalty is applied, *everyone* is penalized, not only the attacker. In other words, scorched-earth.

Soft-forking off the attacker's chain doesn't really work long-term because they can simply attack again and again until they get their way.
Modern PoS-based protocols actually have an amazing feature: *accountable safety*. If a majority re-org is done and a finalized block is unfinalized, at least 1/3 of stake is identifiable as the attacker and can then be burned with off-chain coordination.

arxiv.org/abs/1710.09437
Accountable safety is what allows modern PoS-based protocols to have a substantially smaller security budget than PoW-based protocols while providing the same security (i.e. cost to manipulate history) guarantees.

How does Avalanche Consensus (AC) fit into all this? In AC, the opinion of a node is formed by asking some random subsample of other nodes for their opinion, over several rounds. However, the opinion of a node can flip!

Over several rounds, a node can begin by voting for V, then later vote for the conflicting V'. In other words, equivocating is a feature of AC, not an issue! Which then begs the question: can we have accountable safety with AC?
Consider the following scenario: 90% of stake is malicious and vote for V. After the remaining honest 10% lock in with V, the 90% vote for V'. In this scenario, we know a re-org happened, but do we know which stake specifically caused the attack? The answer is no!
No single party has access to timestamped votes from all stakers, so the complete set of equivocating stake can't be proven non-interactively. Even if it were possible, equivocation is a feature, not a bug, in AC, so such a proof wouldn't do us much good.
Therefore, Avalanche does not have accountable safety, and can only use the scorched-earth policy of nuking coin price permanently for everyone. This is a policy that modern PoS protocols have evolved beyond, as it is brittle and unreliable.
And that's a wrap for today's episode, on penalties for a majority, and how Avalanche Consensus does not provide accountable safety. If you're feeling up for it, use the ideas discussed here to do the analysis for minority penalties and Nothing-at-Stake!

• • •

Missing some Tweet in this thread? You can try to force a refresh
 

Keep Current with John Adler | ✨⛽

John Adler | ✨⛽ Profile picture

Stay in touch and get notified when new unrolls are available from this author!

Read all threads

This Thread may be Removed Anytime!

PDF

Twitter may remove this content at anytime! Save it as PDF for later use!

Try unrolling a thread yourself!

how to unroll video
  1. Follow @ThreadReaderApp to mention us!

  2. From a Twitter thread mention us with a keyword "unroll"
@threadreaderapp unroll

Practice here first or read more on our help page!

More from @jadler0

Jun 23, 2022
SwaySwap, a blazingly fast dex for the Fuel devnet, is out. A short thread on how Fuel @fuellabs_ eliminates the need for token approvals.

This means fewer transactions to interact with a dapp, and no infinite-approvals i.e. more secure in case of hacks.

While ETH can be *pushed* with contract calls on Ethereum, ERC-20 tokens cannot. `approve` and `transferFrom` must be used (in two separate transactions) to first approve an amount of tokens for a receiving contract to *pull*, then for the receiving contract to actually pull.
This leads to poor UX and higher cost: 2 txs instead of 1.

To work around this, many apps use infinite approvals, where you approve the contract to use your entire token balance. Problem: if the contract is exploitable, *all* your tokens are gone.

Read 4 tweets
Sep 26, 2020
What Avalanche is Not, Episode 2

Last episode, we discussed fees and how it's impossible for Avalanche's X-Chain to have non-fixed fees without making fundamental trade-offs. On today's episode: rewards, and how they're similarly impossible.

Let's start by clearing up some confusion from last time. It's not “impossible, period” to have non-fixed fees in Avalanche; rather, it's impossible without making some additional trade-offs to fundamental assumptions or guarantees provided by AC.

The recurring thesis of these threads is that there's no silver bullet solution. Everything is simply a point in the trade-off space. And we'll explore the concessions Avalanche needs to make in order to provide the guarantees and performance it promises.

Read 21 tweets
Sep 24, 2020
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.

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.

Image
Read 16 tweets
Sep 13, 2020
Just published "Nakamoto Consensus Requires Social Coordination and Subjectivity"

TL;DR Nakamoto Consensus, contrary to popular belief, is not objective. It has a subjective component, just like the weak subjectivity assumption required in PoS protocols.

talk.lazyledger.io/t/nakamoto-con…
We've been told for years now by Bitcoin maximalists that PoS protocols require *fundamentally* stronger trust assumptions than PoW, in the form of weak subjectivity (asking a trusted third-party for a checkpoint if you've been offline for a while). We've been told a lie.
It's not that PoS protocols do not require social coordination; rather, it is that Nakamoto Consensus does require social coordination!

How so? It's all in the incentives.
Read 5 tweets
Aug 5, 2020
Optimistic rollups have taken Ethereum by storm as a promising avenue for exploring different execution models and enabling dynamic heterogeneous sharing on Ethereum today.

Here’s a thread on the precursors to ORU: scaling techniques that were so close, but didn’t quite make it.
I’ll be covering two techniques in this thread: the earlier “shadow chains” and the more recent “plasma rollup.” There are many more techniques (too many to enumerate) that share many common features with ORU, but none of these have the exact same properties as ORU.
First up, shadow chains, proposed in 2014. Are shadow chains *literally* optimistic rollups? Let’s find out! Here’s the original post on the Ethereum blog:

blog.ethereum.org/2014/09/17/sca…
Read 27 tweets

Did Thread Reader help you today?

Support us! We are indie developers!


This site is made by just two indie developers on a laptop doing marketing, support and development! Read more about the story.

Become a Premium Member ($3/month or $30/year) and get exclusive features!

Become Premium

Don't want to be a Premium member but still want to support us?

Make a small donation by buying us coffee ($5) or help with server cost ($10)

Donate via Paypal

Or Donate anonymously using crypto!

Ethereum

0xfe58350B80634f60Fa6Dc149a72b4DFbc17D341E copy

Bitcoin

3ATGMxNzCUFzxpMCHL5sWSt4DVtS8UqXpi copy

Thank you for your support!

Follow Us!

:(