| 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.
|
| 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.
|