The Ethereum project is evolving nicely, as things are finally starting to come to fruition after two years of intensive development. Now that the Ethereum Frontier has been established, the time has come to look ahead and focus on more support for the lightweight client. Casper will play an important role in this process, and now is an opportune time to explain what this project is all about.

Also read: Ethereum: Public Consensus Versus Economic Consensus

Casper – Focus on Worst-Case Economic Analysis

When talking about the concept of a digital currency running on a blockchain protocol that has the potential to offer widespread implications, there are various things to take into consideration. In the case of Ethereum, the worst-case economic analysis is the only correct way to analyze consensus protocols intended to be suited for public consensus.

Similar to any other blockchain-based digital currency, there is always the possibility of having an attack against the network. For Ethereum, that attack can come from various angles under the current implementation, including colluding nodes under bad behavior. Every attacker has a certain “attack budget” they control, and it is up to developers to make spending this budget as unprofitable as possible.

Casper is a project created to accomplish exactly that. The main goal is to ensure maximum coverage of Byzantine fault tolerance. At the same time, Casper will disincentivize any attack vector against the Ethereum network, making it expensive for an adversary to bribe a high number of nodes to undermine the entire protocol.

But there is more to Casper than “just” Ethereum protocol security, as the project is designed to be light client-friendly. Also, this new environment will provide a positive experience to DApp developers and users. Casper has the potential to become a powerful tool, as the developers combine low-latency with reporting the state of the finality of transaction receipts.

But What About The Proof-of-Stake Angle?

While Proof-of-Stake is a cost-efficient manner to protect network security, there are also issues that need to be addressed. First of all, there is the “nothing at stake” problem, which means rational Ethereum nodes have no distinction from being Byzantine. Also, nodes with tokens have no effective expenses.



Security-based Proof-of-Stake can solve this problem as it will require information regarding the node’s behavior to be published to the consensus protocol. Doing so will allow severe punishment to be handed out to nodes who partake in bad behavior through Byzantine faults. More importantly, achieving consensus is cheap for everyone, except for adversaries during an attack.

The second problem with Proof-of-Stake is the concept of a long-range attack. Adversaries can control old keys, which can then be used to create a competing version of events. With enough keys under their control, a group of adversaries can attempt to fork the Ethereum blockchain.

Luckily, the developers have already come up with a concept to address this issue, by changing the authentication model state of the consensus. Doing so would allow for signatures only from nodes which currently have something – a balance – at stake. This solution is more secure, as authentication is based on current information, rather than ancient data.

Once again, this is where Casper comes into the picture, as it is much more light client-friendly. Especially in regards to this new authentication procedure, as nodes which are not only sufficient will also have an easier time relying on trusted source to synchronize securely with the Ethereum blockchain.

More information on Casper can be found here.

Source: Ethereum DevCon1 2015

Images courtesy of Ethereum

Also published on Medium.