Skip to content
Back to the collection

Combining GHOST and Casper

Vitalik Buterin, Diego Hernandez, Thor Kamphefner

Show all 9 authors

Khiem Pham, Zhi Qiao, Danny Ryan, Juhyeok Sin, Ying Wang, Yan X Zhang

2020 · arXiv

Read the paper
HN score
0
Mentions
7
Readers
4
Months
4
What’s in a score?

From the abstract

We present "Gasper," a proof-of-stake-based consensus protocol, which is an idealized version of the proposed Ethereum 2.0 beacon chain. The protocol combines Casper FFG, a finality tool, with LMD GHOST, a fork-choice rule. We prove safety, plausible liveness, and probabilistic liveness under different sets of assumptions.

Metadata: arXiv. Abstracts retain their original authors’ rights.

In the conversation

Original HN comments, with labels from simple text rules. A label describes the whole comment and may miss context or irony. Read the discussion to make up your own mind. About the labels

7 selected excerpts · 7 total mentions

Jasper_
Neutral mention · rule
Do you have any explanations of proof of stake? I've tried to read https://ethereum.org/en/developers/docs/consensus-mechanisms... and https://arxiv.org/pdf/2003.03052.pdf but I feel they're intentionally obfuscated. I understand proof of work very well. I tried reading the Tezos proof-of-stake scheme [0], but it seems like it has some very obvious holes that leave security gaps wide open (namely, once you get to somewhere around 50%, probably less, you can completely predict and control the PRNG outputs, giving you full capture of the network), which makes me feel like I still don't quite understand it. I won't go into whether it's exclusionary or not. That depends on…
Read the full comment
your economic viewpoint. Personally, I think they're about the same -- those with the wealth control the network. And they've consistently been pushing back The Merge's launch date less than a month than the go-to date. I remember when they wanted to launch it in April 2022. And then May. And then June [1]. [0] https://tezos.gitlab.io/active/proof_of_stake.html [1] https://eips.ethereum.org/EIPS/eip-4345
676234e117
Neutral mention · rule
If you want more details you can always read the Gasper paper[1], the spec[2], or client code. It is complex to somebody not familiar with consensus and blockchain execution, but you might say that about any modern engineering. PoW is undoubtedly simpler but also exponentially more environmentally destructive. [1] https://arxiv.org/abs/2003.03052 [2] https://github.com/ethereum/consensus-specs/blob/dev/specs/p...
mratsim
Neutral mention · rule
It's a relevant answer to your personal attack "I don't think you've studied how the attack would work." My job is literally implementing proof-of-stake securely. Also when I work and implement an algorithm, I provide references and sources, which my PR is. > The coordinated bribery attack can be done by having people stake on a different chain until a majority is reached and then softfork and slash the minority. Changing the vote is a slashable offense in the Gasper paper (cited in my PR). https://arxiv.org/abs/2003.03052 A change of vote will be ignored and the validator will be deemed malicious and ejected. p17 section 4.7 Slashing conditions with proofs. Furthermore, this has been formally verified https://runtimeverification.com/blog/formally-verifying-fina...
DennisP
Neutral mention · rule
> 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…
Read the full comment
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
DennisP
Neutral mention · rule
Here are the two papers on Casper: Casper the Friendly Finality Gadget: https://arxiv.org/abs/1710.09437 Combining GHOST and Casper: https://arxiv.org/abs/2003.03052 A very simple summary is that it's a fairly traditional consensus protocol, in which if anyone breaks the rules it's possible to prove who did it and penalize them by burning their stake. It achieves scale by using aggregated signatures.
DennisP
Neutral mention · rule
Shard execution isn't necessary for migrating to proof-of-stake. The PoS migration just links a single EVM to the beacon chain; that's enough to remove PoW, i.e. the main concern in this discussion about GPUs. Around the same time is the migration to data sharding, which multiplies data storage by 23X initially. That's without code execution on the shards. Zkrollups in production now do the execution off-chain. On chain, you store compressed state data and a compact proof that everything executed correctly. That's good for a couple thousand tx/sec today, and 23X that after data sharding. Given that, Vitalik has argued that shard execution may not even be necessary; it…
Read the full comment
wouldn't add nearly so much transaction capacity as we'd have already. Here are the papers on how Ethereum consensus actually works: https://arxiv.org/abs/1710.09437 https://arxiv.org/abs/2003.03052 And here's more detail on rollups: https://vitalik.ca/general/2021/01/05/rollup.html

Keep following the thread.

More in Distributed systems

More from the same topics.