I recently reviewed the latest Casper Research Paper in light of an ongoing discussion with Vitalik Buterin over consensus mechinisms. It is my intent to be as objective and practical as possible while recognizing all factors of the greater picture.
One thing that has become abundantly clear in my research is that the various consensus camps have been talking past each other due to a general lack of language precision. For the sake of clarity I will attempt to use the language and terms found in the Casper papers.
There are two parts to the Casper protocol, the proposal mechanism and the consensus mechanism. The proposal mechanism produces a sequence of blocks that link together and the consensus mechanism creates a checkpoint every 100 blocks.
Under the hybrid proof-of-work model Ethereum will use POW blocks as the proposal mechanism and the Casper algorithm to reach consensus on checkpoints.
The proposal mechanism is deliberately kept abstract; this can be a dictator, it can be a round-robin scheme between the participants in the consensus, or, as in our case with hybrid Casper, it will be the original proof of work chain.
Given that the proposal system is abstract, it is trivial to replace it with DPOS. In other words, where Ethereum uses POW we can use DPOS. Note that using POW with casper does require changing the Fork Choice Rule away from the “longest chain” to a new rule that factors in Casper first and only uses longest chain rule to break the tie.
Because the Casper papers keep the proposal mechanism deliberately abstract, their initial proposal mechanism will be proof of work, and I am not aware of any proposed alternative proposal mechanisms, we can skip straight to the consensus mechanism of Casper.
Casper is first and foremost a protocol based on mathematics and game theory. This protocol attempts to reward those who agree while punishing those who disagree. It also has properties that punish all participants if certain objective measures of mischief are observed.
In the Casper protocol there is a set of validators and all validators are expected to send two messages per epoch: PREPARE and COMMIT over their preferred last blocks in the chain of the epoch. The proposed epoch is 100 blocks; under Ethereum an epoch is 1500 seconds, under DPOS it would be 300 seconds.
The bandwidth required grows order N with the number of participating validators and comes at the expense of potential bandwidth for other transactions. It is for this reason that an Epoch is 100 blocks and not 1 block.
With this basic understanding, the EOS community could elect to adopt Casper as a contract to increase the perceived security of their blockchain. The rewards for participation could be funded by one of the 3 community benefit applications elected by stakeholders. Delegated Proof of Stake currently uses the longest-chain rule.
All of this could be implemented without actually changing the EOS protocol or at most tweaking the fork-choice rule to account for information from Casper validators. However, given the almost complete lack of forks in DPOS this hardly seems necessary.
The proposal mechanism determines what transactions get included in blocks and what transactions are censored. It also determines the set of blocks available to the casper consensus process.
The proposal mechanism controls the following aspects of a protocol:
This means that the proposal process is what determines centralization of production and censorship. Shutting down the proposal process shuts down the network as the Casper Consensus process depends upon a valid source of produced blocks. All Casper provides is a economic measure of finality every 30 minutes (Eth POW hybrid) or 5 minutes (DPOS hybrid).
We can conclude from this that the vast majority of the real consensus problems fall within the responsibility of the proposal mechanism. We can also see that Casper does nothing to improve the performance. Lastly, by the time an Ethereum block is buried under 30 minutes of POW the probability of reversal is so small that the relative cost of "casper insurance" likely far outweighs the actual risks involved.
If we allow anyone to propose anything at anytime then Casper validators could reach a deadlock by not knowing which blocks to sign PREPARE messages for. It is in the validators interests to cooperate to reach consensus.
The Casper Validators may be wise to the deadlock issue and agree to “take turns” sending PREPARE messages. In this way the validators always send PREPARE for a valid block which already has the most PREPARE messages. Once we have established that validators will cooperate to schedule and synchronize timing of sending PREPARE messages we can also suggest that the first to send PREPARE will do so for a block that they themselves produced.
Therefore we can model Casper as a protocol of N validators that each submit a PREPARE message at individually allocated time slices, say once every 3 seconds. This means that with a 100 block epoch and 3 second blocks you could have over 100 validators. You could support more validators if you reduce the interval and start allowing multiple validators to submit PREPARE messages in parallel after enough momentum has built up. Think of it as an avalanche started by a single PREPARE snowflake.
While any number of validators is possible, a protocol would be wise to limit the absolute number. My understanding of Casper is that the minimum required bond grows as the number of validators increases. To support scaling Casper expects validators to create pools of bonds and potentially apply multisig to the PREPARE and COMMIT messages.
For bandwidth and performance reasons Casper currently executes one round (called an epoch) every 100 blocks. You could improve upon this by pipelining the epochs so that you have 100 epochs being processed in parallel with a new epoch finalizing every block. If we assume that the validators are taking turns being first to PRODUCE and PREPARE then we can view each DPOS block as a PREPARE message on all prior blocks for 99 prior epochs and a PROPOSE message for a block in the next epoch. In this same pipeline we can consider a PREPARE a COMMIT for the previous PREPARE.
So if you pipeline Casper and make each block Proposal a PREPARE for the current round (epoch 0) and a COMMIT for the prior round (epoch -100) then it is possible to apply the similar slashing conditions while getting much higher performance.
There are two independent parts of the DPOS algorithm:
If you make the producer selection based upon size of the producer bond then you replace voting for producers with producer bonds. If you reinterpret the DPOS block production schedule as a pipelined sequence of Casper epochs then you can apply the Casper slashing conditions while having all the speed and benefits of DPOS.
Under the hybrid POW model, the proposers are selected by proof of work and the validators are selected by those with the highest stake. This hybrid model does nothing to prevent empty blocks or censorship from mining pools. This hybrid stage will eventually give way to some other proposal system, so let's speculate on what that might be.
A reasonable solution is to have the validators take turns producing blocks. The frequency of their selection could either be proportional to stake or independent of stake. If it is independent of stake then this role could be sybil attacked by someone dividing their stake into as many independent accounts as they can fund with the minimum bond. Therefore we prefer stake weighted production.
Under a stake weighted system each “proposer” will produce a block with a frequency proportional to their stake. This would be like the traditional proof of stake system.
We can assume that block producers (proposers) are rewarded with transaction fees and/or block rewards. These rewards can either be socialized or individualized. To keep incentives aligned among the validators it would appear that socialization makes the most sense to encourage cooperation rather than competition; however, under the hybrid POW model being adopted by Ethereum it would be individualized to the miners (aka producers, proposers).
There are two forces at work in Ethereum’s proposal that both tend towards centralization. Firstly, assuming the operating cost for a validating node is constant, the rate of return is proportional to the stake at risk under the proposed individualized rewards structure. Therefore those with the largest bonds in a single pool have the highest rate of return.
Rationally, in terms of raw return on investment, everyone should pool their stake into a single account that certifies all blocks. Not doing this is against the economic best interest of the majority. The end result will likely mirror the distribution of mining pools where there are less than 10 individuals deciding the entire consensus.
Secondly, the operating cost of the validating node actually rises with the throughput of the blockchain. As Ethereum is already straining at around 15 transactions per second, this is an immediate concern. Purchasing and operating top end hardware is going to challenge smaller operations and therefore is another force for concentration (centralization).
At this point it should be clear that Casper is an application layer protocol that can be layered on top of any of the existing consensus algorithms to add check points. What Casper does not solve is the governance problem. Layered on POW governance would be left to block signaling, or layered on proof of stake it would amount to stake weighted direct democracy among validators. Under DPOS governance is multi layered delegation to a panel of equally weighted producers.
Absent a defined and robust governance model blockchains are governed by adhocracy which generally reduces to influence peddling to the largest validators and miners. Decisions over hard forks impact all stakeholders and all stakeholders should have some influence. This influence needs to extend beyond a basic opinion poll which could be ignored by producers, proposers, and validators. The selection of block producers (proposers) needs to be tied to community governance because it is only through the production (proposal) of blocks that decisions of governance are ultimately executed.
One thing is clear, unless a non-technical individual can trivially participate in the governance the interests among all participants on a blockchain will be misaligned. This means that individuals will have to contribute (and risk) their stake to a validator pool. The risk associated with contributing to a single pool is significant, especially if it is uncompensated. The pool operator would take on significant liability and has no incentive to share 100% of the rewards. This in turn means pool operators gain a larger percentage of the rewards.
Just as in Bitcoin and Ethereum, there will be a small number of pool operators who benefit from economies of scale. The more stake a pool has the lower the risk to the pool and the lower the overhead percentage of the operator. In this case people committing their stake to pools are not “voting” based on the politics of the pool, but based on their selfish rate of return offered by the pool operator. Who knows, pool operators may even rent stake to gain a 51% control over the proposal algorithm.
Casper is an interesting algorithm to reward those willing to bet-their-stake on the validity of a block. It remains to be seen what the real-world risk/reward looks like for participating in this game. It is a game where honest mistakes caused by software bugs, network disruptions, or griefing peers may cause unexpected and undeserved losses. This risk may be difficult to access and may discourage participation of honest players. The slashing conditions are a harsh code-is-law kind of governance that leaves little room for honest mistakes that caused no measurable harm (such as accidentally running a backup node with the same key and signing twice). The intention was to maximize uptime and minimize missed epochs, but the outcome was to get slashed.
After all of this effort and game theory, it is still not clear that Casper will result in more relevant security or decentralization than we have with POW and traditional POS. I remain convinced that DPOS provides the best possible proposal algorithm for the Casper consensus algorithm, but I am unconvinced that Casper adds any meaningful value. After all, a properly functioning bug-free version of DPOS produces no forks and achieves irreversible checkpoints 30 times faster.
That said, I think it would be a worthwhile experiment to implement that Casper protocol as an EOS smart contract. Using our concept of Community Benefit Contracts (CBCs) we can propose that Casper be implemented the staked EOS holders vote on how much inflation to reward the Casper contract with, if any at all.
