Raft is a consensus algorithm, and many distributed system uses it, and the Casper consensus protocol includes stake-based bonding, unbonding, and betting cycles that result in consensus.
And usually we use Casper in blockchain, so what's the difference between Raft and Casper consensus algorithm?
Casper is a crypto-economics focused consensus protocol. It is designed as a security deposit based economic consensus protocol. The specific bonded validator nodes in a blockchain network have to place a security deposit in a process known as bonding to produce blocks. It is an adaptation of the Greedy Heaviest-Observed Sub-Tree (GHOST) protocol principles.
Currently there are two variants of Casper: Casper (Friendly Finality Gadget )FFG and Casper Correct by Construction (CBC). Casper FFG will be implemented first. The five parameters of Casper CBC are the names and weights of validators, fault tolerant threshold, consensus values, and estimator. Validators make individual decisions based on their current state, which is defined in terms of the messages received.
In Casper, anyone can participate in block production by posting a bond. Once a bond is placed, there will be a bet on which block included in the text. The incentives are designed such that there will be rewards for betting with the eventual consensus and lose of money by betting against the consensus. All malicious and dishonest behaviour will result in the forfeit of the bond.
In the general sense, Casper is an eventually consistent consensus protocol. Perhaps we can say that it favours liveness over safety. It is always available, and consistent whenever possible. It is robust to unpredictable message delivery times because nodes come to consensus via re-organization of transactions, after delayed messages are eventually received. It has an eventual fault tolerance of 50%, in the sense that a fork created by >50% correct nodes scores higher than any fork created by the remaining potentially-faulty validators.
There is an interesting comparison of different stages of finality in a Blockchain as the chain scales to larger number of nodes. It is represented by Vlad Zamfir in a triangle diagram as below.
Though it is eventually consistent, it is more probabilistic than deterministic. In that sense, it is different to the deterministic nature of Raft. Also the validator in the Casper are information theoretically different from the replicated state machines involved in the Raft consensus. Validators have more privileges than the simple replicated state machines. In Raft consensus we have replicated state machines referring to a log.
There is a minimal synchronicity assumption invoked in Casper consensus. It means nodes come on-line at least once every three months to avoid having their deposits slashed, meaning that unless one-third of validators are actively attacking the blockchain, there are always enough voters available to keep the blockchain safe.
Casper is able to recover from the crash-failure of all but one node. In any case, a validator makes higher returns from producing blocks than from not producing blocks at all. Additionally, bonded validators who appear to be offline for too long will be unbonded, and new bonders subsequently will be allowed to join the validation set. Casper can thereby potentially recover precisely the security guarantees it had before the mass crash-failure.Considering this design, it is quite possible that Casper would be more crash fault tolerant than Raft consensus implementation.
There is a comparison of the finality time of Casper FFG and PBFT by Vitalik in the Ethereum Research Forum. It says that the finality time of Casper FFG would be quite same as that of PBFT with some subtle differences. It is postulating an ever faster finality for Casper CBC. Please refer this discussion here.
Finality Times of Casper FFG and CBC
This answer is only an introduction to this interesting discussion on the comparison between Casper and the mainstream consensus algorithms like Raft and pBFT. Please find my references for further researches in this topic.
