Understand the differences, pros and cons of Greg's namespace proposal and ours.
Discussion items
Time
Item
Who
Notes
5min
Greg's proposal
Greg
Greg was working under the assumption that every validator knows what the set of all validators is. We had been working under the assumption that each small validator set knew the validators in its set, but no others. With Greg's assumption, he can decouple contracts from the validator topology.
In Greg's model, there is a map from validators to the namespace they validate. Contract parameters have a channel sorting that includes a namespace, like "x is a channel in the B namespace on which we can receive names from the A namespace". Given that information, one can check at contract deployment time whether there are resources deployed to process the contract. If not, then there are various choices how to force/motivate validators to cover that namespace.
Greg's model is orthogonal to our model. His organizes the interior of a validator set; ours groups validator sets together.
Concerns
Greg/Mike
If you don't know a set of validators for the chain or subset of the chain, there is a significant security issue, because a cartel could pose as signers. They could pose as validators. Per Mike - if you are using any blockchain, you need to shop around anyways, because there is no set of validators that are known. Greg - my proposal has a list of validators in the genesis block. Mike - even with ETH, you have to shop the validators. Whenever there is a change in validators, it has to be recorded in the block.
If you have this idea that there is a top level, you could have another chain that encompasses it. Ex: embed RChain into another blockchain. We could write contracts that interface RChain with BTC and ETH.
Action items
Type your task here. Use "@" to assign a user and "//" to select a due date.