| Time | Item | Who | Notes |
|---|
| High level review | | - Vitalik had an insight, and several other persons did also at the same time.
- Every major consensus algorithm can be transformed into a protocol by implementing slashing conditions.
- Participants in the protocol have to 'pay to play'. You can't participate without a stake.
-
|
| | What is a Slashing condition | | - 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.
- Griff McClellan (Unlicensed) - will there be false positives in the cryptographic evidence?
- Nash Foster - What computational requirements does it have? How fast does it have to be?
- Lucius Meredith - Let's separate performance for now. Let's talk spec, and then optimize later.
- Lucius Meredith: Why do this? Turns the protocol into an Economic game. Using economics as part of the security mechanism.
|
| What Vitalik has done:
| | - 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.
|
| What is special about 2/3rds for consensus |
|
|
|
|
|
|
| Vlad's version: Justification Pointers | | - 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.
- Michael Stay (Unlicensed) - in - send me that
- 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.
|
| From the other side of the protocol | | - 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 synchony 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.
|
| Problems? | Lucius Meredith | - Winner - what if they do bad things?
- What about overlapping decision sets? participant A wants to decide all transactions happening between 5 am - 9 am in the Pac NW. Participant B that wants to decide all transactions between 7 am and 11 am. Do we need an exclusion? Exclusive control? Other?
- Is there a nice algorithm that allows us to apportion the transactions properly?
|
| Problems? |
| - Joining and leaving the protocol - fraught with interesting and problematic security issues. Need stake for the genesis block of participants
- When can they cash out and leave?
- When can they join the protocol?
- It has to be blind. You cannot see the nature of the transactions, if a participant can see if new participants are joining → cartel behavior
- Could also punish participants and not let them leave.
- Let's say that you discover that some percentage of participants are bad actors. The frequency with which they can join the protocol is critical because every client has to have a reliable understanding of who the participants are. A client needs to not have to be online constantly to know what the bonded participants are in the protocols.
- Michael Stay (Unlicensed): How does a Node know the canonical set of blocks that are relevant to the namespace? Lucius Meredith: We extend the bonding protocol, to include the namespace that the node will operate in.
- Former user (Deleted) - is there a central namespace that is used for bootstrapping? Lucius Meredith - No - you can split that up.
- Bonding and unbonding have transaction fees.
- We have skirted most of the network time issues, we can deal with those separately.
- All of Vitaliks work have a relationship between block size and time. Lucius Meredith: would like for time to be as loose and lax as possible. Need to be free of a network time service.
- Million dollar stake for a billion dollar transaction. How do we prevent the network from colluding itself and stealing everything.
- Limit the deciding power to be the deciding power of the stakes.
- You may a vast majority of the content of the transactions be blind. Participants don't know what the content of the transaction. Validation is only agreeing on the winner of races. You don't have to compare transactional values, you only need to validate if the inputs and outputs match with each other. You can obscure the relationship between that decision and any transactional value.
- Michael Stay (Unlicensed): What about the situation where something is providing a service, ex: Content delivery. How do you validate that they didn't just return you garbage? Lucius Meredith that is validation beyond just picking the winner. That is a separate performance guarantee. If the content provider signs the content, it's easy. Non crypto API's will need to provide a Crypto signature in order to interact with the blockchain.
- Former user (Deleted) - it feels like the namespaces have to be hierarchical - like DNS - do you think that we can do better? Lucius Meredith - I think so yes, but I haven't thought about it or written anything down. You could look to computational shapes (like a forest) -and pick a namespace that way.
|
| Closing comments | Lucius Meredith | - There will be versions of this protcol that are read only - ex: Streaming content - which will be different from applications where there is a great deal of read / write.
- There will be versions that are optimized for heavy duty read/write.
- Want people thinking about these protocols like we think about data structures. Want people to feel comfortable with the general space & the state of affairs.
|
| Questions | Chris Kirkwood-Watts | - In proof of work, miners have an incentive to pick the right chain against which to make a choice.
- In proof of stake - there is a series of bets that are made against forks, it feels that the validator could just create a block with a set of transacitons to assemble the block. there isn't motivation to muck with the chain at all.
- The Fork Choice rule is a module in the protocol. You use slashing conditions involved. there are different criteria in chosing a fork, and you incentives validators to select the right chain. it's the longest chain with the most stake. If Validators select a different branch, and there is cryptographic evidence to the others that they did so, they get slashed.
- Who evaluates the evidence? the other participants - There is a separate condition do deal with Collusion.
- You have to be a validator in order to give evidence.
- Do you think there will be a market for validators to just give evidence? Without a reward? There are people thinking about validator roles. Question around who watches the watchman.
- Vlad has a version of the protocol that is straight up round robin. Little hesistant about weighted versions, because you can get whales. Want a protocol that is egalitarian so that we have a variety of players that can say what's live. Otherwise you get titled distribution.
- Percentage of transaction fees is related to your stake. → Incentive to put in stake & become a validator.
- How do we avoid high jacking a high value transaction? There is a distinction between the logic that you can do this particular arithmatic operation, which is an opcode in a VM that has been verified, which is distinct from 'who is the winner of this race' There are 2 peices of computation that we need to secure - 1) the deduction of Rev from a space 2) the winner of the race.
- Michael Stay (Unlicensed) - the only the validators get to do is determine which of the messages get to have access to the continuation. They don't get to change the message itself.
- There is a for comprehension that is sitting there waiting for a message on a channel. The validators only decide which message.
- Lucius Meredith: The danger is that the validators could favor messages from one party versus another. This would be collusion or disinterest. Don't know how to stop that from happening. If several validators collude, they could throw stake at one participant and favor them.
- Michael Stay (Unlicensed) - if we fell back to Vitalki's version would it be fast enough? Would the speed of RChain be impacted by the decision, or is namespace sharding enough? Lucius Meredith - I believe that namespacing should be sufficient. Now we really need to get down to the engineering and prove that. For sure, the speed of the consensus algorithm has a major impact to our tps rates. That isn't the end of the story, because for us, we have variable block sizes and can be very large. The other thing we are getting consensus on, is not just the winner of races of lists of transactions, but we also describe the ordered sets of transactions via programs, these then expand into a much larger set. We are employing the standard compression to the blockchain. The way you get conflict is if the validator disagree with respect to the ordering of the transactions. Even if the algorithm is slower, we can stuff more transactions into any given block.
- Michael Stay (Unlicensed) - Not sure I know how well the transactions are going to compress. Lucius Meredith - ex: trading data, highly regular, very compressible. For a lot of application markets, the transactions should be highly compressible. I agree for random contracts, there is a challenge.
- Lucius Meredith - if we hit 1,000 tps, we still leave the others in the dust. Everyone will move over. That gives us plenty of time to hit the mark.
|