[jude-]

> Everybody gets the exact same rate of return regardless of how much they have staked.

I don't think that's true. The amount of ETH created per block is determined independently of the amount of ETH staked. So if you stake 100 ETH and I stake 100 ETH, and we're the only stakers, then the protocol gives us each 50% of the ETH minted. But if someone else comes along and stakes 200 ETH, then you and I only get 25% each.

This means that staking rewards are zero-sum. If the total reward stays constant, then my rewards per block increase if your stake decreases and mine stays the same (or if mine increases and yours stays the same). Therein lies the problem -- if I'm going to remain competitive with you, then I need to re-stake as much of my ETH block rewards as you do in order to keep receiving ETH at the same rate as you.

[DennisP]

The total ETH created does depend on the amount staked. Here's a table[1] and formula[2]. The total reward doesn't go up linearly with the number of validators, but it does go up. Lowering the incentive for attacks like you mention is a reason for that.

And while having fewer validators gives you a somewhat higher reward per validator, it's still that case that all validators get the same reward in any given block. Everyone is equally competitive. Someone who reinvests will get higher absolute rewards than they got before, but they pay the price of locking up more capital.

In the same way, a miner could reinvest profits into more mining equipment, but that doesn't make them more competitive, just bigger. Their profit margin will be the same (barring economies of scale that don't exist in staking).

[1] https://docs.ethhub.io/ethereum-roadmap/ethereum-2.0/eth-2.0...

[2] https://github.com/ethereum/eth2.0-specs/blob/dev/specs/phas...

[jude-]

> The total ETH created does depend on the amount staked. Here's a table[1] and formula[2].

Thank you! I was unaware of this. I stand corrected.

However, my original point stands under the added constraint that we don't have enough tokens to alter the yield (i.e. staking our tokens won't push the total staked quantity across a "yield boundary"). The difference in participation between two different yields is considerable, so I would expect this to be the common case.

> Everyone is equally competitive. Someone who reinvests will get higher absolute rewards than they got before, but they pay the price of locking up more capital.

Joining later puts you at a disadvantage, because you have to buy coins off of people who could be staking them. That's problematic from a resiliency perspective, because it makes it harder for new block-producers to come online. It also means that there's no "reserve capacity" in the system to tolerate the sudden loss of a large number of staked coins. This isn't true in PoW, because obsolete miners that aren't profitable to run today could be brought online in a pinch if enough profitable ones were to suddenly go offline.

> In the same way, a miner could reinvest profits into more mining equipment, but that doesn't make them more competitive, just bigger.

These aren't comparable. I could come up with a better, more efficient way to generate PoW outside of the protocol. But in PoS, the protocol mandates that I only use staking to increase my coin income. Per my original point, what this means in practice is that there will come a point where it's cheaper to increase my staking yield by DDoS'ing staking nodes, who will be slashed as a result (the link you gave indicates that the slashing begins after 25 minutes of over 33% of the staked tokens being knocked offline).

[DennisP]

Not sure if this is what you meant but there's no actual "yield boundary," it's a continuous function. The table just gives examples of the function outputs.

I think you're overestimating the amount of ETH that will stake. Right now it's just 3%, and they think it's unlikely to go over 30% or so. ETH is used for a lot of stuff besides staking, with major uses so far including collateral for stablecoins and other defi, NFT purchases, and trading. The daily ETH trading volume right now is $34 billion, which is more than triple the staked amount.

Also, while losing over 1/3 results in a loss of finality, we'd be losing something that doesn't exist in PoW networks in the first place. The network continues to run[1], with a nonzero but low chance of reverted blocks, while the quadratic inactivity leak burns away stake until 2/3 of remaining stake is active again.

DDoS that knocked out over a third of the network, running on ISPs and hosting services all over the world on various independently-developed clients, would be quite a feat, and not likely to be sustained for very long. Since there will likely be plenty of non-staking ETH, more stake will be deposited after the attack, bringing the network back to the equilibrium of satisfactory returns. Or, if the attack were so severe it scared people off, then the price of ETH would also be affected, reducing the value of the attacker's stake.

[1] https://ethresear.ch/t/explaining-the-liveness-guarantee/422...

[jude-]

> Not sure if this is what you meant but there's no actual "yield boundary," it's a continuous function. The table just gives examples of the function outputs.

Yes, I see that now. Thanks again for the clarification (honestly, I wish they just put out a graph like literally everyone else does). Let me see if I can formulate my point now with their continuous function:

You had said up-thread:

> And while having fewer validators gives you a somewhat higher reward per validator, it's still that case that all validators get the same reward in any given block. Everyone is equally competitive. Someone who reinvests will get higher absolute rewards than they got before, but they pay the price of locking up more capital.

First, I think you meant "it's still the case that all staked coins get the same reward in a given block" (emphasis mine). The system doesn't know how many distinct validators exist, since a single entity can just simulate a bunch of entities.

Second, the fundamental issue here is that you have to do something that's at least as profitable (in ETH) as re-staking your coins to remain competitive with other stakers. Because staking ETH is intrinsically tied to block production, this has an impact on the system's overall resiliency with respect to how quickly new honest block producers can be brought online: honest block producers need to buy their way in. The higher the yield on ETH, the higher the barrier to entry for new block producers -- the equivalent to "difficulty adjustments" in PoW would be the price and yield of ETH crashing.

From a resiliency perspective, that's pretty bad -- the only way for new honest block producers to be able to afford to enter the system is to either (1) wait for the system to shit itself so badly that the market devalues it to the point where they can afford to join, or (2) amass enough wealth that they can buy the coins. Part (2) is problematic because this wealth threshold can easily be higher than the wealth threshold required to attack the network itself. For example, it could be cheaper to just steal coins, or bribe other people to cause competing block producers to get slashed.

Which brings me to your point here:

> Also, while losing over 1/3 results in a loss of finality, we'd be losing something that doesn't exist in PoW networks in the first place. The network continues to run[1], with a nonzero but low chance of reverted blocks, while the quadratic inactivity leak burns away stake until 2/3 of remaining stake is active again.

First, "loss of finality" here is the same as a liveness failure. A distributed system that implements a consensus algorithm using decisions made by fewer than 2/3 of the decision-making participants (staked coins in this case) cannot be BFT, by definition. You can't put a probability on finality here either (i.e. "low chance of reverted blocks" is a nonsensical statement), because if over 1/3 of the staked coins are malicious and under the control of an adaptive adversary, then the adversary always has a way to stop the remaining 2/3 from ever reaching agreement. Your only recourse here is to declare out-of-band that these coins are bad, manually and permanently slash them via a code patch, and restart the network by decree (at which point, what's the point of having a blockchain?)

Second, this means that there does not exist a BFT agreement algorithm that removes votes from the system with less than 2/3 of the original votes. Like, how do nodes even agree in a BFT way on who to slash? How do they even agree in a BFT way that it's been long enough for them to carry out a slashing? Again, because the over-1/3 of the coins are not participating honestly, and because the system must be BFT, this means that there's always a way for that over-1/3 coins to prevent the under-2/3 coins from deciding these things.

Now, it doesn't have to be this way. The problem of recovering from BFT liveness failures has been investigated before [2], even before Bitcoin existed, and one approach to recovery is to cause the system to permanently split into two systems (i.e. fork), with 2/3 votes on one side and 1/3 on the other. Maybe this is what Ethereum 2.0 will do? But if so, that kinda breaks the promise of finality -- it's up to each use to choose which fork represents the fork that did _not_ get compromised, and without PoW, it's really one validator set's word against another's (of course, both forks' sets will insist up and down that the other is the corrupted fork -- they're financially incentivized to do so).

> DDoS that knocked out over a third of the network, running on ISPs and hosting services all over the world on various independently-developed clients, would be quite a feat, and not likely to be sustained for very long.

Maybe this data is out of date by now, but as of September 2019 over half of ETH nodes run in datacenters (and of those datacenters, most run in Amazon) [1]. If these datacenter operators kill VMs or delay their network traffic (and to be clear, accidental outages do happen), then the coins staked on these VMs will get slashed. Also, the question to ask here what the distribution of distinct network paths that exist between staked coins looks like. If there are not many distinct network paths between staked coins -- i.e. if there are a few "choke points" in the network -- then these become the points of failure in the entire system. A BGP prefix hijack or a cut cable can lead to liveness failures, and whatever slashing behavior takes place from that.

> Since there will likely be plenty of non-staking ETH, more stake will be deposited after the attack, bringing the network back to the equilibrium of satisfactory returns.

If over 1/3 of the staked coins go offline, there's no way for the network to agree in a BFT manner on anything. That includes deciding to admit new ETH to staking.

> Or, if the attack were so severe it scared people off, then the price of ETH would also be affected, reducing the value of the attacker's stake.

If the attacker only cares about causing a liveness failure, the value of the ETH is presumably unimportant. The goal has been met.

[1] https://thenextweb.com/news/ethereum-nodes-cloud-services-am...

[2] https://www.usenix.org/conference/nsdi-07/beyond-one-third-f...

[DennisP]

> if over 1/3 of the staked coins are malicious

So now you've escalated the attack to be a 33% staker, which I don't think you'd mentioned before. I'll note that 33% of stake is likely to cost more than 50% of mining hardware, and certainly would at the high levels of staking you're concerned about.

> The system doesn't know how many distinct validators exist

Each validator has 32 ETH. If you want to stake more, then you run more validators.

The system does continue running with a split chain, each side apply the leak to the other side. Seems to me if the network reconnects, the side with the most stake would automatically be chosen as the winner, and if somehow the network never reconnects, then a working chain in each might be what you want.

To the extent that social decisions are necessary, this 2014 post on "weak subjectivity" is the first to address your objection to that sort of thing:

https://blog.ethereum.org/2014/11/25/proof-stake-learned-lov...

At this point, I'm going to just suggest learning more about how the system actually works. A good starting point is these papers:

Casper FFG: https://arxiv.org/abs/1710.09437

Combining GHOST and Casper: https://arxiv.org/abs/2003.03052

[jude-]

> So now you've escalated the attack to be a 33% staker, which I don't think you'd mentioned before.

I mentioned it in my original comment, reproduced below:

"The unstated gotcha here is that the chain operates through a variation of BFT agreement where staked coins vote for new blocks. All the usual BFT constraints apply -- namely, if fewer than 66% of the staked coins can reach a quorum, the chain stalls. This would mean that the network is only as resilient as the nodes that contribute the least-resilient 33% of the coin votes."

Also, as mentioned before, the cost attacking the network is not the cost as buying 33% of the staking coins. The cost to attack the network is the minimum of either buying 33% of the coins, or compromising 33% of the staked coins' nodes and forcing them to misbehave. Either way, you get a liveness failure.

> The system does continue running with a split chain, each side apply the leak to the other side

It may, but it is definitely not operating in a BFT manner at that point any longer. There is no in-band recovery from an attacker that compromises 33% or more of the staked coins, since they can forever stall the network. Contrast this to PoW, where an attacker that controls 33% or more of the mining power can be dislodged by the honest participants acquiring more mining power (since hashes/sec, not coins, determines who can produce blocks).

> To the extent that social decisions are necessary, this 2014 post on "weak subjectivity" is the first to address your objection to that sort of thing:

In other words, you have to trust somebody to resolve forks for you out-of-band. Note that PoW does not have this deficiency -- when presented with two conflicting chains, the one with the highest cumulative PoW is the "true" chain.

> At this point, I'm going to just suggest learning more about how the system actually works. A good starting point is these papers:

I've read both, and there's nothing special about them that invalidates anything I've written above.

The points I raised in this thread are distributed systems 101 material. Maybe the Ethereum team should pick up a textbook.