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.
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.
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.
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.
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.
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!
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: