Expressed in a proof of stake protocols, all play to play.
Bootstrapped of the genesis block. Record of the bonded validators and their stakes exists on the block.
Relies upon certain properties of communications within the protocol. When there is cryptographic evidence of violations of the conditions, this results in a penalty against the stake.
If enough penalties are accrued, then the validator can no longer participate in the protocol.
Looked at PBFT - he worked with Yoichi to do Isabel proofs of his slashing condition PBFT - there is some confidence that his version of the protocol does what it needs to do. If nothing else, we can use the PBFT slashing condition and call it CASPER
Much simpler version from the PBFt: Friendly finality gadget: If 2/3rds are committing, then your requirement is to commit.
Greg proposed to Vlad that we use justification pointers, the rational and design motivation for using these go back to Branskey & H Game theory
In order to be able to express properties like 'single threadeness' they had to use justification pointers.
In a protocol exchange if a client is talking to a server. The justification is authorization, that you are allowed to use the server. Initial messages are automatically justified. Later in the protocol there needs to be a reason for the request. The message comes with the justification for the message itself.
This basic idea shows up in session types.
The justification pointer will record the history of the message that is coming in now.
For example: Bad justification If a client sends a closed session without a justification of an open session , that is not cool.
In the case of distributed consensus there are multiple participants - where they are making bets. you can include the crypto identity in the protocol. this allows you to look at things like single threadedness. Vlad was looking at the notion of equivocation - the basic idea being that if you have gossiping going on, if a participant gives 2 different bets with the same justification, (in the case of RChain they are betting on the winner of races) - participant A says that the left participant wins on a channel, and to another says that the Right participant is winning on a different channel with the same justification (this is equivocation)- in a setting like that it is easy to look at the evidence and it's hard to tamper with the Justification structure.
Why do this? Vlad believes you don't have to be so heavy handed about the 2/3rds protocol. Instead what you do- you look at the situation where a participant is about to send out to the other participants a bet/position behind a list of winners of the races. what they want to do at this point is analyze the situation. Is there anything that would be able to change my mind about the bet? can I receive information that would change my position? If they have already seen all of the stake weight behind a particular stake weight and it is 51% - Then the race is already won. They are trying to run an analysis where and adversary may change their mind. Then they can make a bet that is safe.
Griff McClellan (Unlicensed) - What is the race? Is it for a nonce? For RChain blockchain, the only consensus that has to be developed - In the concurrent I/O events that are happening, there is a likelihood of race conditions. The clients are racing against each other to get seats. All the copies of the contract that are running all need to agree on who the winners of the races are. Contention for communication events.
Nash Foster - how feasible is it to run a simulation?
Lucius Meredith: There are situations where this is computationally harsh. Vlad has done a lot of work looking at lower bounds. Not sure where he has ended up. No access to code to see for myself.
However the impt. point here, is that there is a lot of play between the 2/3rds and Vlads extremely dynamic and flexible ideal adversary calculation. This is why I talk about CASPER as a family of protocols. There is a great deal in between all of these. We could just do PBFT - but we want to do much better.
Nash Foster - do we have plans for a fallback? we should have a canonical fallback? Lucius Meredith - yes we will have a canonical fallback with a slashing conditions. We are looking at versions of the protocol that have more intelligence and are safer. We want to get to consensus faster. He is able to show frequently that he gets convergence very fast.
It is interesting to compare with Tendermint - it suffers reboot situations, where the protocol just stops. You have to throw away the state and begin again. Vlad's version is significantly better.
Looking to set up a market around choice. You pay other participants for the option to say who the winner of the race is. It flips the protocol around. there you have a limiting factor - you can get this waffling back and forth - which is why Vlad implements this tie breaker condition. Given a particular set of messages, a participant is justified in changing its mind, and sending out a bet for a different set of winners, and then another participant is justified in changing its mind. But you need to prove that this oscillation will eventually result in convergence.
The FLP impossibility only happens under asynchronus situations. So we apply a synchonisy requirement. Turning synchony constraints into economic constraints.
A participant can observe that the others have put 49% stake behind 1 winner, so they add a new justification and change their mind.
If you say that participants are paying for the right to decide race winners. This lines up with how we are thinking about namespaces. 'I want to be the decider to be the winner of races in these namespaces - and I'm willing to pay this much over the base transaction fees' Now this becomes an economic game. It's a way of turning a synchrony constraint into an economic constraint.