Or, what is Casper finality?
Normal operation of the Casper proof-of-stake consensus protocol leads to the output of a property called finality on the data that participants in the process are coming to consensus on. We call this data finalized because once achieved, the data cannot be changed without provably burning more than 1/3 of the collateral put down by the participants in the system. It turns out that this property adds some nice security guarantees that are currently lacking in existing proof-of-work systems.
One way to think about Casper is that validators (the analogue to proof-of-work’s miners) in the system are tasked with voting on blocks in the that they deem “canonical.” Rewards are given in the case that an individual validator agrees with the others (encouraging consensus on the single chain) and penalties are levied under proof of malicious behavior (like trying to vote for two distinct forks of the chain). Penalties are applied against a bonded deposit (“the stake”) that is required to be locked under the system’s control before a given validator can participate.
The security of 2.0 is derived from the total amount of these deposits along with some rules (the “slashing conditions”) that ensure that validators who attack the consensus lose their deposit. To give some flavor for the security margin, a consensus failure on 2.0 will require a violation of the slashing conditions by more than 1/3 of the active validators on the network. Assuming a level of 10M ETH participating in the system, a successful attack would imply the burning of around 3.3M ETH which at the time of writing is valued at over $500M.
Given the magnitude of this security margin, any data deemed canonical by the Casper process is said to be final in the sense that it would require a catastrophic act to undo the “canonicalization.” This property of finality contrasts with the guarantees of Nakamoto consensus which only makes probabilistic statements about the safety of a given piece of data in terms of proof-of-work performed on top of it (cf. “confirmations” in the ). Rather than assume the will not revert after some height via the revelation of a fork with more work, the 2.0 consensus will know (up to economic certainty) that the after some point will never revert. Think about any time you have tried to make a deposit or withdrawal at an exchange and had to wait for some number of blocks (usually, a long time) before the operation was considered complete to get a sense of the utility of finality — in a finalized system, you would only have to wait for the natural consensus to occur once to consider your operation complete.
Published at Fri, 10 May 2019 00:31:58 +0000