Ethereum Stepping Stones: Constantinople And Casper

Ethereum’s Byzantium hard fork was only one half of a two-part process designed to transition the decentralized application platform to a new method for reaching consensus – proof-of-stake. The next hard fork, called Constantinople, was recently discussed during an Ethereum core developer meeting and could include Vitalik Buterin’s Casper update.

“Theoretically, Casper may well be at the stage where we may actually just try doing it for the next fork,” said Buterin, referring to Constantinople, “even if that sounds ambitious.” When moderator Hudson Jameson asked Buterin to elaborate on Casper, Buterin responded, “Hybrid proof-of-stake. The finality gadget.”   

Ethereum developers and researchers are currently exploring two flavors of Casper: Casper FFG and Casper CBC.

Casper FFG (Friendly Finality Gadget) is Buterin’s iteration of a proof-of-stake consensus algorithm. Per the updated Casper FFG whitepaper, “Casper is a partial consensus mechanism combining proof-of-stake algorithm research and Byzantine fault-tolerant consensus theory.” This change will essentially be an overlay atop Ethereum’s current proof-of-work blockchain.

In Buterin’s iteration, proof-of-work would propagate the blockchain as usual. However, every fifty blocks, a “checkpoint” will interrupt the chain and proof-of-stake will verify consensus through finality validators. This is why Buterin’s version of Casper is a hybrid proof-of-work/proof-of-stake partial consensus mechanism.

Casper CBC (Correct By Construction) is the brainchild of Ethereum’s game theory phenom Vlad Zamfir. Generally speaking, Zamfir’s design is a departure from status-quo protocol design. Typically, protocols are fully complete before implementation. Zamfir’s design begins implementation with a partial protocol and builds to a complete protocol via input from a safety oracle, or what Zamfir refers to as “an ideal adversary.” In Zamfir’s model, an estimate safety oracle will raise exceptions of a fault or identify potential future faults. Simply put, Zamfir’s version of Casper places emphasis on protocol architecture in such a way that a local view of a particular node’s estimate of safety is used to reach consensus safety for the entire network.

Basically, Casper FFG is a road map for gradually switching Ethereum to proof-of-stake and Casper CBC is more of a method of securing a proof-of-stake system. Although details about ultimate Casper implementation are sparse, the final rendition of Casper will likely draw aspects from both of these methods. The step away from proof-of-work, which relies heavily on electricity and hardware, is on a path that Ethereum’s core developers have been planning for years now.

ETHNews will be following Casper development closely and will provide updates as they become available. Buterin concluded the core developer meeting by saying, “It should be done … I would say very soon. The parts that aren’t done are fine details of the contract. The actual spec of the fork is not going to be particularly complex. It’s basically just increase the balance of a contract then change the fork choice rule by adding a couple function calls going into the Casper contract. If those details change, that would not affect anything of the client implementation by much.”