3 ms·

Thanks for this. Can you further explain the part about forking being easier from point 5?

ChadNauseam 4y ago
For sure. In this comment I'll be using "validators" to mean "nodes participating in consensus". The "true" chain according to the new protocol is the one that has more signatories. Validators sign blocks as they're produced, and when a block gets more than 2/3rds of the signatures, it's finalized on the chain and won't be rewritten. (Well, it's much more complicated than that, but that's the general intuition.) When you sign a block, you get a reward on that chain, to incentivize people to participate in consensus. So the question is, when there's a fork, what stops people from just signing blocks on both forks so they get the signing reward no matter which fork "wins"? The protocol disincentivizes this by requiring validators to put up a stake of 32 eth, that gets "slashed" if you do that. Put another way, if there's a fork and you sign blocks on both sides of the fork, you lose part of your stake. But that threat only works if you actually have a stake to lose. If it's been ${withdrawal_delay} months and you no longer have any eth staked, you can start signing blocks from a long time ago and the protocol can't slash you as punishment. So a group of 2/3rds of the former-validators could freely start a fork from ${withdrawal_delay} months ago, sign a bunch of blocks on it, and if their fork loses they'd face no penalty. Someone currently participating in consensus can see this is happening and won't be confused, but someone just joining the network will be. The solution is pretty easy, if inelegant. When entering the network for the first time, if there are multiple competing forks, you'll just find someone you trust IRL and ask them which chain is the real one. If you've been offline for less than ${withdrawal_delay} months, you won't have to worry about this, but it is a problem for fresh users. If you set ${withdrawal_delay} to infinity, this isn't a problem, but probably you don't want to do that. Once withdraws are enabled, there'll be some tooling to make it easy to figure out which chain is the real one, but I don't expect there'll be many forks that are remotely convincing.
- getcrunk 4y ago
  Thanks!
yokem55 4y ago
In theory, a very large staker could run a large share of the network, exit (either normally or get slashed), then rewind the chain prior to the exit, run it on their own independently, and then pop up after a while with a competing fork. This makes syncing from the beacon chain's genesis risky because you could end up following the attacker's fork. To make up for this risk, Ethereum then relies on distributing recent 'weak subjectivity' snapshots (through other known nodes, block exploers, baked into client releases, etc) to make sure new folks can join the legitimate network and ignore an attacker's. Those snapshots basically rely on social legitimacy to help folks get going with the 'legitimate' chain. It is a trust assumption. In contrast (at least in theory), in a proof of work network you can 'objectively' determine which of competing forks of a chain is the legitimate one by a simple metric, the 'longest chain with the highest difficulty'. The presumption made here though is that you will have an open internet and honest client software that will not censor the legitimate chain. A trust assumption is still made that those that introduce you to the p2p network aren't hiding a longer chain from you.
- cypress66 4y ago
  Something to keep in mind is that you already mostly need such trust. You are using that "social legitimacy" to know you are downloading the legitimate software, or viewing the legitimate source code, or documentation. Your computer can't calculate if ethereum.org is the legitimate "Ethereum", or it's ethereum.io (just making it up).

For sure. In this comment I'll be using "validators" to mean "nodes participating in consensus". The "true" chain according to the new protocol is the one that has more signatories. Validators sign blocks as they're produced, and when a block gets more than 2/3rds of the signatures, it's finalized on the chain and won't be rewritten. (Well, it's much more complicated than that, but that's the general intuition.) When you sign a block, you get a reward on that chain, to incentivize people to participate in consensus. So the question is, when there's a fork, what stops people from just signing blocks on both forks so they get the signing reward no matter which fork "wins"? The protocol disincentivizes this by requiring validators to put up a stake of 32 eth, that gets "slashed" if you do that. Put another way, if there's a fork and you sign blocks on both sides of the fork, you lose part of your stake. But that threat only works if you actually have a stake to lose. If it's been ${withdrawal_delay} months and you no longer have any eth staked, you can start signing blocks from a long time ago and the protocol can't slash you as punishment. So a group of 2/3rds of the former-validators could freely start a fork from ${withdrawal_delay} months ago, sign a bunch of blocks on it, and if their fork loses they'd face no penalty. Someone currently participating in consensus can see this is happening and won't be confused, but someone just joining the network will be. The solution is pretty easy, if inelegant. When entering the network for the first time, if there are multiple competing forks, you'll just find someone you trust IRL and ask them which chain is the real one. If you've been offline for less than ${withdrawal_delay} months, you won't have to worry about this, but it is a problem for fresh users. If you set ${withdrawal_delay} to infinity, this isn't a problem, but probably you don't want to do that. Once withdraws are enabled, there'll be some tooling to make it easy to figure out which chain is the real one, but I don't expect there'll be many forks that are remotely convincing.

getcrunk 4y ago
Thanks!

yokem55 4y ago

In theory, a very large staker could run a large share of the network, exit (either normally or get slashed), then rewind the chain prior to the exit, run it on their own independently, and then pop up after a while with a competing fork. This makes syncing from the beacon chain's genesis risky because you could end up following the attacker's fork. To make up for this risk, Ethereum then relies on distributing recent 'weak subjectivity' snapshots (through other known nodes, block exploers, baked into client releases, etc) to make sure new folks can join the legitimate network and ignore an attacker's. Those snapshots basically rely on social legitimacy to help folks get going with the 'legitimate' chain. It is a trust assumption. In contrast (at least in theory), in a proof of work network you can 'objectively' determine which of competing forks of a chain is the legitimate one by a simple metric, the 'longest chain with the highest difficulty'. The presumption made here though is that you will have an open internet and honest client software that will not censor the legitimate chain. A trust assumption is still made that those that introduce you to the p2p network aren't hiding a longer chain from you.

cypress66 4y ago
Something to keep in mind is that you already mostly need such trust. You are using that "social legitimacy" to know you are downloading the legitimate software, or viewing the legitimate source code, or documentation. Your computer can't calculate if ethereum.org is the legitimate "Ethereum", or it's ethereum.io (just making it up).