Greetings to all – Vlad speaking. Since September 2014, I’ve been engaged in the evaluation and outlining of “proof-of-stake” blockchain structure. While Vitalik and I have not reached agreement on every aspect of the specification, we share consensus on numerous attributes of the proof-of-stake protocol that are likely to be enacted for the Serenity launch! It is referred to as Casper “the friendly ghost” as it represents an adaptation of certain principles from the GHOST (Greedy Heaviest-Observed Sub-Tree) protocol, transitioning from proof-of-work consensus to proof-of-stake. This blog entry (my inaugural one!) conveys properties that are expected to characterize Casper’s implementation in the Serenity launch. Formal verification and simulation of Casper’s attributes are currently in progress and will be published in due course – in the meantime, feel free to indulge in this high-level, unofficial discourse! : )
Security-deposit based security and authentication
Casper is an economic consensus protocol grounded in security deposits. This stipulates that nodes, referred to as “bonded validators,” must place a security deposit (an action we term “bonding”) to contribute to the consensus by generating blocks. The protocol’s direct governance of these security deposits is the main method through which Casper influences the incentives for validators. In particular, if a validator generates anything that Casper deems “invalid,” their deposit is forfeited along with the right to partake in the consensus process. The utilization of security deposits tackles the “nothing at stake” dilemma; that acting poorly incurs no cost. There is a risk involved, and bonded validators who act in a demonstrably improper manner will suffer a loss.
Significantly, a validator’s signature is economically relevant only as long as that validator currently holds a deposit. This indicates that clients can solely depend on signatures from validators that they are aware of as currently bonded. Hence, when clients receive and validate the consensus state, their authentication chain culminates in the list of currently-bonded validators. In contrast, with proof-of-work consensus, the authentication chain concludes at the genesis block – possessing knowledge of the genesis block allows you to validate the consensus. In this case, possessing knowledge of the set of currently-bonded validators enables you to validate the consensus. Clients who lack awareness of the currently bonded validators’ list are required to authenticate this list out-of-band. This limitation on how the consensus is validated addresses the “long range attack” concern by mandating that everyone validates the consensus against contemporary information.
The validator list evolves over time as validators place deposits, lose their deposits, unbond, and get unbonded. Therefore, if clients remain offline for prolonged periods, their validator list may no longer be up-to-date enough to validate the consensus. However, if they are online frequently enough to observe the rotating validator set, they can securely refresh their validator list. Even in this case, clients need to begin with a current list of currently-bonded validators and, as such, they must authenticate this list out-of-band at least once.
This “out-of-band authentication necessary but once” characteristic is what Vitalik refers to as weak subjectivity. In this context, information is termed “objective” if it can be validated in a manner defined by the protocol, while it is “subjective” if it must be authenticated through means outside the protocol. In weakly subjective consensus protocols, the fork-choice rule is stateful, and clients must initiate (and possibly occasionally renew) the information that their fork-choice rule utilizes to authenticate the consensus. In our situation, this involves identifying the currently bonded validators (or, more likely, a cryptographic hash of the validator list).
Gambling on Consensus
Casper obliges validators to wager a significant portion of their security deposits on the anticipated outcomes of the consensus process. Additionally, the consensus process “unfolds” in the manner of their wagers: validators are compelled to wager their deposits based on how they expect others to wager theirs. If they bet accurately, they reclaim their deposit alongside transaction fees and potentially token issuance based on it – conversely, if they fail to reach a swift agreement, they recuperate less of their deposit. Consequently, through iterative rounds of betting, validator wagers converge.
Moreover, if validators dramatically alter their bets, for example by voting with a high likelihood on one block after previously voting with very high likelihood on another, they face stringent penalties. This ensures that validators place high-probability bets only when they are confident that fellow validators will also submit high-probability wagers. Through this mechanism, we ensure that their bets do not converge on a second value after initially converging on a first, provided that there is adequate validator participation.
Proof-of-work consensus is likewise a wagering system: miners wager that their block will belong to the heaviest chain; if they ultimately prove correct, they earn tokens – whereas if they turn out incorrect, they bear electricity costs without remuneration. Consensus is upheld as long as all miners are wagering their hashing power on the same chain, making it the blockchain with the most work (as a direct consequence of and as anticipated by their coordinated wagers). The economic expense of these proof-of-work wagers accumulates linearly with the number of confirmations (developments of descendant blocks), while in Casper, validators can collaboratively place exponentially increasing portions of their security deposits against blocks, thereby achieving peak security very swiftly.
By-height Consensus
Validators independently wager on blocks at every height (i.e., block number) by assigning it a probability and publishing it as a wager. Through repeated betting, the validators select exactly one block at each height, and this determines the sequence in which transactions are carried out. Importantly, if a validator ever places bets with probabilities summing greater than 100% at any moment for a specific height, or if any are below 0%, or if they bet with more than 0% on an invalid block, then Casper will forfeit their security deposit.
Transaction Finality
When every member of a supermajority of bonded validators (a group of validators who meet a protocol-defined threshold somewhere between 67% and 90% of bonds) bets on a block with an extremely high (for instance, > 99.9%) probability, the fork-choice rule will never accept a fork where this block does not prevail, and we describe this block as final. Additionally, when a client observes that every block below a certain height H is final, the client will not choose a fork that presents a different application state at height H – 1 than the outcome resulting from the processing of transactions in these finalized blocks. In this eventuality, we denote this state as finalized.
Thereare consequently two pertinent types of transaction finality: the finality of the fact that the transaction shall be carried out at a specific height (which stems from the finality of its block, thus holding precedence over all subsequent blocks at that height), and the finality of the consensus state post the execution of that transaction (which necessitates finality of its block and of distinct blocks at all lower heights).
Censorship Resistance
One of the most significant threats to consensus protocols is the emergence of coalitions that seek to optimize the gains of their members at the cost of non-members. For instance, if the earnings of Casper’s validators largely consist of transaction fees, a majority coalition could suppress the remaining nodes to secure a larger portion of those transaction fees. Moreover, an adversary might bribe nodes to exclude transactions related to specific addresses – so long as a majority of nodes act rationally, they can suppress the blocks created by nodes that incorporate these transactions.
To counter attacks from majority coalitions, Casper perceives the consensus process as a cooperative game and guarantees that each node maximizes its profit if it is part of a coalition consisting of 100% of the consensus nodes (at least as long as they are primarily incentivized by in-protocol rewards). If p% of the validators are engaged in the consensus game, then they receive f(p) ≤ p% of the earnings they would gain if 100% of the validators were involved, for some increasing function f.
Furthermore, Casper imposes penalties on validators for failing to generate blocks in a protocol-specified order. The protocol is cognizant of deviations from this sequence and accordingly withholds transaction fees and deposits from validators. In addition, the revenue accrued from accurately betting on blocks increases linearly (or superlinearly) with the number of validators participating at that height of the consensus game.
Will there be more transactions per second?
Most likely, yes, albeit this is attributable to the economics of Casper rather than its blockchain architecture. Nonetheless, Casper’s blockchain facilitates quicker block times than what is achievable with proof-of-work consensus.
Validators are expected to earn primarily transaction fees, hence they have a direct motivation to increase the gas limit, provided their validation server can handle the increased load. However, validators also experience diminished returns from causing other, slower validators to desynchronize, thus they will only upscale the gas limit to a level that is manageable by the other validators. Miners focusing on hardware typically acquire more mining rigs, while validators emphasizing hardware primarily upgrade their servers to process more transactions per second. Although miners are also motivated to reinvest in more potent transaction processing, this motivation is considerably weaker than their desire to obtain mining power.
Security-deposit-based proof-of-stake is highly favorable to light clients when compared to proof-of-work. Particularly, light clients do not need to download block headers to achieve full security in authenticating the consensus or to obtain complete economic guarantees of valid transaction execution. This indicates that a significant amount of consensus overhead affects only the validators, not the light clients, enabling lower latency without compromising light clients’ ability to verify the consensus.
Recovery from netsplits
Casper can recover from network partitions as transactions in non-finalized blocks can be reversed. Upon reconnection of a partition, Casper executes transactions from blocks that attracted bets on the partition with higher validator participation. This way, nodes from either side of the partition concur on the state of the consensus following reconnection and before validators can alter their bets. Validator bets align to finalize the blocks in the partition with greater validator participation, with a very high likelihood. Casper is expected to process the transactions from losing blocks after those from winning blocks, although it is still undecided whether validators must include these transactions in new blocks or if Casper will execute them in their original sequence, autonomously.
Recovery from mass crash-failure
Casper can recover from the crash-failure of all but one node. Bonded validators can consistently generate and place bets on blocks independently; however, they generally achieve higher returns by collaborating with a larger group of validators in block production. In any scenario, a validator obtains greater returns from block production than from abstaining entirely. Furthermore, bonded validators deemed offline for an excessive duration will be unbonded, allowing new bonders to join the validation set. Consequently, Casper is capable of potentially restoring the exact security assurances it possessed prior to the mass crash-failure.
What is Casper, in non-economic terms?
Casper is a consensus protocol based on an eventually-consistent blockchain. It prioritizes availability over consistency (refer to the CAP theorem). It remains perpetually available, and achieves consistency whenever feasible. It is resilient to unpredictable message delivery times as nodes reach consensus by reorganizing transactions after delayed messages are ultimately received. It has a fault tolerance of 50% in the sense that a fork produced by >50% correct nodes holds greater significance than any fork formed by the remaining potentially faulty validators. Importantly, clients cannot ascertain that any particular fork created with 51% participation will not be reverted, as they cannot determine whether some of these nodes are Byzantine. Accordingly, clients only recognize a block as finalized if it has encountered participation from a supermajority of validators (or bonded stake).
What is it like to be a bonded validator?
As a bonded validator, one needs to securely sign blocks and place bets within the consensus process. If possessing a significantly large deposit, it is likely one will have a few servers set up in a custom multisig arrangement for validation, reducing the likelihood of server malfunctions or hacks. This will necessitate experimentation and technical know-how.
The validator should remain online consistently and for as long as possible to maximize its profitability (otherwise it may become unprofitable). Acquiring DDoS protection would be highly advisable. Furthermore, your profitability is contingent on the performance and readiness of the other bonded validators. This implies there are risks that you cannot directly control. One could incur losses even if other nodes fail to perform well – however, losses would be greater if one chooses not to participate at all after bonding. Yet, additional risk often corresponds with higher average profitability – especially if the risk is acknowledged but the adverse event never materializes.
What is it like to be an application or a user?
Applications and their users gain significantly from the transition from proof-of-work consensus to Casper. Reduced latency notably enhances the user’s experience. Under normal circumstances, transactions finalize very swiftly. In moments of network partitions, however, transactions continue to be executed, but the potential for them to be reverted is clearly communicated to the application and end-user. Therefore, the application developer must still navigate the possibility of forking, as they would in proof-of-work, yet the consensus protocol itself offers a clear indicator of what it would require for a particular transaction to be reversed.
When can we hear more?
Stay tuned! We will be sure to provide you with more information on Casper’s specifications in the coming months, as we reach consensus on the protocol’s particulars. Additionally, you can anticipate seeing simulations, both informal and formal specifications, formal verifications, and implementations of Casper! But please be patient: R&D can take an unpredictable amount of time! : )