As high-level as possible without losing important meaning, what's the intuition behind GHOST? How is it currently implemented in Frontier? What will be different with GHOST in Casper?
GHOST is short for the Greedy Heaviest Observed Subtree chain selection rule which was a proposed modification for the Bitcoin blockchain (Paper).
GHOST orignally was a protocol modification, a chain selection rule, that makes use of blocks that are off the main chain to obtain a more secure and scalable system.
With that modification, it is possible to speed up the blockchain to a velocity of up to 1 block per second. The result is a general higher possible transaction rate without compromising the blockchain consensus and security.
Ethereum implements a simplified version of GHOST which only goes down seven levels. Specifically, it is defined as follows:
- A block must specify a parent, and it must specify 0 or more uncles
- An uncle included in block B must have the following properties:
- It must be a direct child of the kth generation ancestor of B, where 2 <= k <= 7.
- It cannot be an ancestor of B
- An uncle must be a valid block header, but does not need to be a previously verified or even valid block
- An uncle must be different from all uncles included in previous blocks and all other uncles included in the same block (non-double-inclusion)
- For every uncle U in block B, the miner of B gets an additional 3.125% added to its coinbase reward and the miner of U gets 93.75% of a standard coinbase reward.
This limited version of GHOST, with uncles includable only up to 7 generations, was used for two reasons. First, unlimited GHOST would include too many complications into the calculation of which uncles for a given block are valid. Second, unlimited GHOST with compensation as used in Ethereum removes the incentive for a miner to mine on the main chain and not the chain of a public attacker.
Casper began life as an adaptation of the principles of GHOST to security-deposit-based PoS. The most complex version of Casper uses a subtree-choice rule, executes all transactions and includes bets from blocks that are included in the dependency graph of winning blocks, and can do sub-network latency confirmations.
Vitalik's PoC of Casper is much simpler to specify and implement, however, bets and transactions need to be directly included in winning blocks to have an effect on the consensus state. Not very GHOSTy, but the name "Casper" has stuck, anyways.