Casper as an EOS Contract | 将 Casper 作为 EOS 智能合约
I recently reviewed the latestCasper 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.
根据与Vitalik Buterin 对共识机制正在进行的讨论，我最近对最新的Casper研究论文做了一些修订。我尽可能做到客观和实用，同时考虑到更广的图景中的所有因素。
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.
Two Parts of the Problem 问题的两部分
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.
提议机制刻意保持抽象性; 它可能是一个独裁节点，也可以是参与者之间达成共识的循环方案(round-robin scheme)，或者，就像我们在混合Casper机制中的例子一样，它是原始的工作量证明链。
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.
考虑到提议系统的抽象性，使用DPOS替换它是无关紧要的。换句话说，在Ethereum使用POW的地方，我们都可以使用DPOS。注意，Casper使用POW确实需要改变“分叉选择规则”(https://medium.com/@VitalikButerin /minimal- slashs-conditions-20f0b500fc6c)，从“最长的链”转移到一个新的规则即Casper优先的规则，最长链规则只被用来打破僵局。
Casper Protocol Messages Casper协议信息
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.
在Casper协议中，有一组验证人，所有的验证人预期会在每一个周期发送两条消息: 准备并提交(PREPARE and COMMIT )他们在epoch的链中所选择的最近的多个区块。提议的epoch是100个区块;以太坊中epoch是1500秒，在DPOS机制下是300秒。
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.
Casper as an EOS Application 作为 EOS 应用的Casper
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.
有了这些基本理解，EOS社区可以投票选择采用Casper作为智能合约，以增加区块链的直觉上的安全性。参与者的奖励可以由利益相关者选出的3个社区福利应用之一资助。委托权益证明机制(Delegated Proof of Stake)目前使用的是最长链式法则。
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 Importance of the Proposal Mechanism 提议机制的重要性
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:
When is a block produced
Who produces it
What transactions are included
Potentially who gets the fees
When hard forks are adopted
What soft forks are enforced
The speed of short-term transaction confirmation
The probability of short-term forks
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.
My Proposed Proposal Mechanism 我提出的提议机制
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.
尽管有可能会有任意数量的验证人，但协议的明智做法，是限制验证人的绝对数量。我对Casper的理解是，随着验证人数量的增加，最低要求的bond也会增长。为了支持Casper扩容，希望验证人能创建一个 bond 池，并潜在地将多重签名( multisig )应用在准备和提交消息上。
DPOS is Pipelined Casper DPOS与Casper管道相连(pipelined)
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.
如果你将Casper管道化，让每个区块为当前这一轮(epoch 0)提出一个准备信息, 并且为前一轮（epoch -100）提起COMMIT信息，也许可以在得到更高性能的同时，使用类似的削减条件(slashing conditions).
Two Phases to DPOS
There are two independent parts of the DPOS algorithm:
Selecting the Producers
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.
如果基于生产者的bond大小选择生产者，那么就会将投票选择生产者替换为根据producer bonds来选择的方式。如果重新将DPOS生产调度阐释为Casper epochs的管道顺序，那么可以在拥有DPOS的速度和优势的同时，使用Casper的削减条件(slashing conditions).
Validator and Proposer Selection 验证人和提议人选择
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).
Bias toward centralization 中心化的倾向
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).
其次，验证节点的运行成本实际上随着区块链的吞吐量而上升。由于 Ethereum 每秒钟处理大约15笔交易已经吃紧了，这是一个迫在眉睫的问题。采购和运行高端硬件将威胁较小的运行者，因此是另一种集中(中心化)的力量。
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.
Casper是一种有趣的算法，奖励那些愿意将自己的权益押注在一个区块的有效性验证上的人们。在这个游戏中，现实世界的风险/回报是什么样子还有待观察。这个游戏中，由软件错误、网络中断或恶意破坏的节点(griefing peers)所造成的无心之过，可能会导致意外和不应得的损失。这种风险可能很难获得(access)，可能阻碍诚实玩家的参与。削减条件(The slashing conditions)是一种哈希代码即法律的治理类型，它为造成无法估量损失的无心之过，留的空间很小(比如不小心将一个备份节点用同样的密钥和签名运行了两次)。目的是最大限度地提高正常运行时间，并尽量减少错过的epoch，但结果却被削减了。
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.
荆凯，程序员，坚信区块链将会改变潮水的方向。欢迎加微信: shuke0327，或者关注公众号: 增长之道