Regions are how we are doing static annotations in the source code.
We are still unclear on how a validator can work on a subset of the entire blockDAG and still be able to do anything worthwhile.
We are worried about transitive closure properties when we have races across regions.
Gets worked out in the static annotations
This assigns contracts to regions, assignment of validators is still unclear. → Mike
Understand the dependency relationships for each region. Has a path up to the root. Kent has a diagram in his proposal.
Mike - it requires each validator to validate all the transactions it has and all the ones above it?
No - Greg- only the transactions that impinge upon it.
Kent - you want to have some control over your parents because they control you. Reviews Nash's proposal.
Key point is that the transactions that impinge upon both sides of the lower regions. the static analysis up front has figured out for us these dependencies
Nomenclature
Sharding solution is needed in order to be confident about the numbers we are speaking about publicly. Does anyone have a problem with the position that we need Sharding?
Concern is from ETH, because all miners are competing for the global state lock. All the sharding work is to avoid the global state lock. However, we naturally have a lot more room in RChain just by the nature of sending and receiving and we are not doing these big long computations as big chunks of trace that we are committing to.
Greg - that is debatable - I can put lots of math inside a send.
Mike -straight line code can't affect anything else. It doesn't need a lock to do that computation. Greg- that is not what we are calling a transaction, its where you have I/O (COMM Event)
Our COMM events are much more finely grained, they are commutative unless they are on the same channel. State lock is needed until there is contention.
Mike - it's not clear to me that we will have ETH's issue.
We can avoid a global state lock by the use of names.
We can only shard on processes or names.
Processes wiggle, we can't easily shard on processes. Greg doesn't know how to do it right now.
Names are much more stable and they line up with transactions very nicely. Seems to be the path of least resistance.
Michael - the payment solution needs to shard in the exact same way. Greg - agrees.
Greg: A shard will correspond to a group of names.
Arrange the code so we understand the groups of names. Provided an algorithm from Andy Gordon.
Michael - Declarative aspect to the regions in the Pi Calculus, not obvious to him what the groups of names will look like and how we will declare them. We want to load balance the shards ideally.
Greg- think of groups of names as logical entities. They are not necessarily tied to physical resources in a way that is constant. The groups of names might have different resources assigned to them at different times. Similary to IP server farms.
Michael - I don't follow that. If we see a COMM event as a fundamental computational event - then Michael Birch (Unlicensed) I missed this part.
It has to be tied tot he RChain notion of computation. Michael and Greg agrees.
Greg- we cannot force people to write good code.
Now we need to assign validators to the groups of names such that we have security and consistency.
Distinction - There are effectively 2 different type systems, 1 is about structure, say something is a pair, I should be able to break it into 2 pieces. This is structural typing.
Namespace idea is breaking up into chunks based upon their structure
Nominal Typing - Language java - foo pair and bar pair- even tho the internal structure is the same - the name foo is different from the name bar - therefor if you try to type check a foo as a bar, they won't typecheck. Unless you have put a relationship in place.
The name name group proposal is a Nominal typing - 'collecting a group of names' - Decorated within the program. We calculate post facto what names are in the group by analyzing the program, and once we have calculated that, we post calculate a predicate that would select out that name.
The reason we want to name these name groups, is because we want to add meta-data about he kinds of resources that can serve them, like validators, they have to provide some kind of proof that they have certain capacities - ex storage, bandwidth, uptime
How this affects policy - when we select validators, on the metadata that is supplied in addition to the other kinds of criteria - include what is known about their load and stake.
By calcuating the name groups upon which we will shard upon the contracts, we give contract owners back control. Impinges upon the policy of selecting validator.
Need to consider how the child validator relates to the parent validator.