Ethereum releases Casper v0.1: A short description for validators
The following is a summary of key tips released by Casper team for validators.
Casper the Friendly Finality Gadget (FFG) version 0.1, released by the Ethereum team last week is an improvement to the Ethereum network. The Hybrid Casper FFG combines proof of work (PoW) with proof of stake (PoS) consensus. It is “a separate process that runs in parallel with proof of work and finalises blocks, giving them additional security.” Ethereum plans to eventually transition to PoS from PoW to improve the economic values for users by reducing the cost per transaction and increasing the number of transactions per second. The new version does not provide scaling but is an essential step towards a lighter network. According to the Ethereum Improvement Proposal (EIP) #1011, the aim of the new version of the protocol is to reduce the block reward for miners to 0.6ETH from 3ETH now.
Validation of the Casper protocol is performed by validators. Validators apply to join the validator set by sending a transaction containing the ETH stake they want to deposit, the “validation code”, which is a generalised public key that specifies a computer program to be used to verify their signatures, and the return address where their deposit will be sent to when they withdraw. The validation code is a piece of EVM code and input that shall pass as a 32-byte message hash plus a signature. The gas limit is 200k. There is freedom in terms how to use a validation code, with some having elliptic curve verification (ECRECOVER), quantum-resistant hash ladder sigs, and additionally multisig, threshold signature and keys that can authorise other keys. Validators usually do not choose the validation key in practice, depositing money and running the validation code that the client generates by default, setting a withdrawal address and publishing the transaction automatically. The validator can choose his withdrawal address that can be a cold wallet. As a result, the money cannot be stolen from the validator, causing just the appearance of misbehaviour and penalty in the worst case.
The deposit transaction for a validator is set at a minimum of 1,500ETH. If validators have fewer funds available, they can join a stake pool. Casper FFG splits into a series of epochs. Every fiftieth block in the chain is called a checkpoint, and the period between two checkpoints is called an epoch. At every epoch, Casper FFG gives the validator the ability to send a “vote” transaction; this transaction will vote for some particular checkpoint. In a hybrid version Casper is not a full consensus algorithm. It processes over proof of work blockchain, already created on Ethereum blockchain. The purpose of Casper is to finalise blocks, and give them security. If two thirds of validators vote for a checkpoint, the checkpoint is justified. If two check points in the row are justified, the block is finalised. The new validator gets inducted as a validator in approximately two dynasties or 45 minutes on average.
Once validators sign and send a deposit transaction, after 45 minutes, they are staking. Every epoch, when the validator node signs and deposits transaction, sending a “vote” message, the validator will participate in the consensus and needs to stay turned on and connected.
Rewards and penalties have not been finalised by the Ethereum team yet. An initial suggestion is that, assuming 10m ETH are deposited: the reward for staying online and voting would be 0%-5% per year; the penalty for going offline would be 5–10% per year or more in extreme circumstances; and the penalty for making conflicting votes would range from from 1% to 100% and getting logged out.
Validator returns are proportional to the inverse square root of total deposits. That means that if total deposits go up 2%, an individual validator’s interest rate falls 1% and total issuance rises 1%. If there are only 2.5m ETH participating, a validator can make an annual return of 10%. If 40m ETH are participating, a validator can make an annual return of 2.5%.
Collective rewards and penalties are implied within the Casper protocol, incentivising validators to vote. Validators’ rewards depend not just on whether they vote, but also on whether or not other validators vote. If a validator does not vote, the penalty becomes even bigger if other validators do not vote. If everyone else behaves perfectly, a validator only needs to be online half of the time to be profitable.
Casper introduces a “quadratic leak”, whereby validators may lose an amount from their deposits which is quadratic in time during whwhen no one votes: after 1 week, some 5% of deposits will be lost; two weeks, 20%; and three weeks, 50%. If more than one third of validators stop voting correctly and blocks stop finalising, non-voting validators’ deposits start to leak more quickly until blocks start finalising again. Voting validators get zero rewards (but not penalties) during this phase.
A validator gets slashed for submitting two votes that contradict each other. The Casper protocol has two conditions under which a validator may be slashed: a validator cannot make two different votes in the same epoch, and a validator cannot make a later vote which references an earlier source than an earlier vote. If a validator gets slashed, they get logged out, must pay “collective penalties” as a non-voting validator for the next four months or a minimum of 2% of their deposits, and suffer a penalty of 3p* of their deposit where p is the portion of other validators that also get slashed within four months of the validator. The slashing mechanism incentivises validators to set up their security to have failure modes that are maximally discorrelated from everyone else’s failure modes. According to the game theory, if a validator gets hacked during an attack while others get slashed, they may lose a great deal. It is better to fail alone. The slashing mechanism disincentivises validators from participating in the same staking pool, using the same VPS, the same operating system and sample implementation as everyone else.
The logout procedure with the withdraw function happens when a validator enters either an online key or a withdrawal address that initiates a logout procedure and withdrawal. Log out procedure happens every 700 dynasties (if each dynasty is approximately 20 minutes, this translates to roughly one per week). Once logged out, the validator will be able to recover their funds in four months. If the chain is under attack, the logout may take more than a week.
If a validator does not have the necessary 1,500ETH stake, they can join a staking pool. There is a minimal size of stake because in the current non-scalable version of Casper, there is a limit for supporting validators. In a sharding network, the minimum stake will be lower. The main differences between staking pools will include: reliability, size, deposit or withdrawal conditions, and centralised or decentralised (using threshold signatures between participants). Validators will be able to participate in the experimental sharding system with a minimum deposit of 32ETH.
It will take some time for the network to understand the risks and benefits of the new protocol. The transition from 14–15tx/sec Ethereum to a faster network is required for further network development.
This report is for informational purposes only. It is not intended as an offer or solicitation for the purchase or sale of any financial instrument or as an official confirmation of any transaction. All market prices, data and other information contained in this document has been prepared from sources believed to be reliable, but we give no representation or warranty that the information is complete, accurate or current. Past performance is not a reliable indicator of future performance. Not for further distribution. Investments in cryptocurrencies associated with essential risks, including risk of losing 100% of value. Not for the distribution in countries where digital assets are recognized as illegal.
NKB Group
Offices: London, Vienna, Bratislava
https://www.linkedin.com/company/NKBGroup
https://twitter.com/theNKBGroup
The report is prepared by NKB Group in collaboration with Hypothesis Research Ltd (UK).
