In this chapter, I will retell the birth story of Casper mechanism with the application of GHOST (Greedy bush-Observed Sub-tree (GHOST protocol) principle designed by Aviv Zohar and Jonatan Sompolinsky in the proof of claim.

I call it “the friendly Ghost” (editor’s note: see the cartoon “casper” of the original title), it is because the design is a series of incentives to ensure that resistance against oligarchs monopoly shielding, the incentive mechanism can force the cartel alliance (monopoly) more friendly to those not cartel validator.

Resistance to shielding in cartel models

February 2015 — Friendly encouragement

After seeing how oligopolies work, I began to look for a way to design proof-of-interest agreements that would thrive even after a cartel was formed. And what must be achieved in this new agreement is that the cartel does not shield the incentives of validators who are not in the cartel.

I realized that when performing a cartel analysis of proof-of-work consensus, a cartel with 51% of miners had an incentive to block miners who were not in the cartel. These 51% will be rewarded with more money immediately, and will eventually be rewarded with more blocks (after the block difficulty is adjusted).

I’ve already seen the advantages of proof of equity over proof of work, the proof of equity agreement gives access to “witch proof funds (deposits)”; On the contrary, the workload proves that blockchain does not directly control mining computing power.

So I realized that the proof-of-work protocol would not be able to detect the existence of a shield because, after all, proof-of-work exists outside the protocol. Furthermore, in my case, this leads me to one permanent feature of Casper:

Cartels cannot hide the absence of verifiers that have been blocked.

This means that cartels do not cover up the fact that there is a “missing verifier that has been blocked.”

So IT was clear to me that it was possible to construct agreements in which cartels had no incentive to block other verifiers. Plus, it’s pretty easy. In such a protocol, cartels must be penalized when validators are missing (blocked). And the punishment is severe enough, and long enough, that it is no longer in its interest to block non-cartel members.

I began to get excited. This shows that proof of equity is fundamentally more resistant to blocking than proof of work, and thus helps confirm my previous intuition that “safe deposit margin is the most important”.

And we can see how this protocol is implemented: if one verifier fails to incorporate a block into the chain, all those who successfully incorporate a block into the chain are penalized. This also tells us clearly that the cost of blocking resistance in the cartel model is that “one validator deliberately goes offline to cause other online validators to lose money”.

Because it is difficult for the protocol to know whether the validator is being shielded or deliberately taken offline for its own benefit, it is necessary to punish the relevant offline validator.

I immediately suggested to Jae Kwon and Ethan Buchman that their Tendermint should adopt the rules I described above. However, they turned me down because they felt it was unacceptable to punish all verifiers just because some of them were offline. Jae also points out that blocking is not a problem because it will be discovered by the community, which can quickly resist the cartel’s actions and stop using the blockchain.

I half-heartedly agree with Jae on this point, but I don’t think this is a reason not to make every possible attempt to ensure that cartels don’t block other non-cartel members.

The definition of decentralization

February or March 2015

Sometime in early March (or was it February?) Matthew Wampler-Doty offers an interesting definition of decentralization:

Whether a protocol is decentralized or not depends on whether it can be restored to normal operation with only one node after all nodes are permanently deleted.

This definition is biologically inspired, just as mycelium can recover with the help of a single cell. This point is interesting because it leads us to note that Tendermint is not as decentralized as traditional blockchain protocols such as proof-of-work protocols, or PPC or proof-of-stake protocols in NXT.

Tendermint can’t recover without a hard fork without two-thirds of the equity-weighted verifiers in the network to effectively sign blocks. In contrast, Bitcoin, PPC, and NXT were able to recover with only one miner or equity owner remaining online (although it took them a lot of time to create blocks).

The birth of the friendly GHOST

March 2015 — Certificate of interest for GHOST Encounter

Vitalik and Gavin Wood were scheduled to meet me in London in mid-March, and I should have been able to detail a proof-of-interest agreement to them by then, but I was nowhere near ready.

So, in despair, I dived for the first time into the literature on traditional Byzantine fault-tolerant consensus mechanisms. But I didn’t learn much. However, I do make one thing clear: the literature is almost entirely focused on consensus protocols that only make “security decisions” (which presumably means “only build certain blocks on which all nodes that follow the protocol can ultimately agree”). And these consensus agreements, like Tendermint, never have any forks.

I find that traditional Byzantine fault-tolerant consensus protocols require a usable “Byzantine Quorum” (

So I decided THAT I needed a consensus protocol for usability preferences, rather than a protocol that just made “security decisions” (compatibility preferences). I need a protocol that can actively build blocks so that even when a validator is working, that validator can still build a blockchain.

Final determinism (whether or not it is possible over traditional protocols) can be achieved by using Byzantine node-sets (if available) to make decisions after the block is created.

Vitalik and Gavin were already at my door, and with some confusion and desperation, I made a decision: I would adapt GHOST to the proof of claim. I’ve come to know and love GHOST because it affects part of ethereum’s detailed specification for proof of work.

I firmly believe that the verifiers will produce a DAG (directed Acyclic graphs, English Wikipedia, Chinese Wikipedia) of blocks and “validation signatures” (electronic signatures on blocks that will prove their validity and consensus weight). In this GHOST, there will be a function that accepts any similar DAG and returns the “simplest” transaction ordering. A record of all consensual actions will be kept in the DAG and used as a motivator.

Of course, if any verifier frequently fails to put their blocks into the simplest order, then every verifier will be penalized.

Although the agreement is not entirely feasible or exhaustive, it is comprehensive enough. I have enough confidence to make it work.

Here is a protocol model with specific properties of these:

• A verifier builds blocks if necessary.
• The DAG captures all the information that a verifier might find useful to the protocol incentive mechanism.
• Cartel blocking can be punished.

I gave Vitalik and Gavin a detailed account of what I had done. Although none of them were impressed (after all, they were expecting a detailed description of the agreement), they could see that I was doing enough work to justify the money I was making (so I didn’t do it often!). .

Casper was born as a simple “friendly GHOST”, modified to accommodate proof of interest, and completed with incentives that encourage cartels to be “friendly” to non-cartel validators.

From “friendly GHOST” to “Casper: Friendly GHOST”

Long before John Dilley convinced me to call this protocol “Casper” at Jeremy Gardner’s “Crypto Castle” party in San Francisco, Several people have already told me to name the friendly GHOST “Casper” (sadly, I can’t remember exactly who suggested it).

At this party, I was a little nit-picky about Andrew Poelstra’s idea of a safe deposit margin to solve disinterested and remote problems. (Don’t worry, dear readers, he and I have had a good chat for the rest of the day.)

In the following chapters, Casper history will mention…

In the next few chapters, I will describe my efforts to define Casper DAGs’ “standard sequencing” functionality. This will include the exploration of “consensus with blocks” (which happened before the party that helped me name Casper). Finally, this long post will end in Berlin in July 2015, where Vitalik and I finally figured out how to make Casper integration final.

Link to the original article: https://medium.com/ @vlad_zamfir/the-history-of-Casper-chapter-5-8652959cef58

By Vlad Zamfir

Translation & Proof: Lola & Elisa

This article is reprinted from Ethereum aficionados.

The original link: https://ethfans.org/posts/the-history-of-casper-part-5