Namespace  

  RSS

Jerry
(@jerry-2)
Active Member
Joined:4 months  ago
Posts: 6
01/05/2018 1:40 pm  

 

Suppose there are three regions 

  • Region a
  • Region b
  • Region c

Each region hosts its own namespace, (e.g. region a serve namespace A), then we have  three primitive namespaces.

  • Namespace A (served by region a)
  • Namespace B (served by region b)
  • Namespace C (served by region c)

And namespace joins.   then there are more namespaces

  • Namespace A Union B (served by region a + b)
  • Namespace B Union C (served by region b + c)
  • Namespace A Union C (served by region a + c)
  • Namespace A Union B Union C (served by region a + b + c)

Above all, region a/b/c produces namespaces A / B / C / A∪B / A∪C / B∪C / A∪B∪C.  So namespaces are power-set of regions.

First question: Is the namespace A∪B∪C the root one in the hierarchical namespace tree?

I got impression that namespaces made up a hierarchical  tree. So here A∪B∪C is the root node in that tree, right?

Second question : How are transactions organized in blockDAG across namespaces?

  • wallet X whose main purse x lives in namespace A.
  • wallet Y whose main purse y lives in namespace B.

Now transfer 1 REV from wallet x to wallet y. I imagine it would happen in following steps 

  1. create a new purse x' and transfer 1 REV from x to x'
  2. transfer purse x' ownership from wallet X to wallet Y
  3. transfer 1 REV from x' to y

Are they correct?

So

  • I assume step #1 occurs in namespace A and is recorded in the blockDAG of region a. Right?
  • I assume step #3 occurs in namespace B and is recorded in the blockDAG of region b. Right?
  • What's important is step #2, it occurs in namespace A∪B and involves both regions a+b, I am curious how it is recorded in the blockDAG's of region a and region b
    • From what I see region b only cares if region a released the ownership while region a only cares if region b acquire the ownership. So they record their own part?
    • namespace A∪B is more like a conceptual namespace and it does not have its own blockDAG?

 

Thanks for clarifying,  I am newbee on board so I am trying to understand how namespace actually works.


ReplyQuote
Medha
(@medha)
Member Admin
Joined:6 months  ago
Posts: 11
01/05/2018 2:53 pm  

We are in the process of writing the specification for namespaces.  Once we have it specified, and we are clear on the approach, we will post the answer and a link to the specification here.  Your understanding is quite good.


ReplyQuote
Mike Stay
(@stay)
Member Moderator
Joined:4 months  ago
Posts: 19
01/05/2018 5:03 pm  
Posted by: Jerry

 

Suppose there are three regions 

  • Region a
  • Region b
  • Region c

Each region hosts its own namespace, (e.g. region a serve namespace A), then we have  three primitive namespaces.

  • Namespace A (served by region a)
  • Namespace B (served by region b)
  • Namespace C (served by region c)

And namespace joins.   then there are more namespaces

  • Namespace A Union B (served by region a + b)
  • Namespace B Union C (served by region b + c)
  • Namespace A Union C (served by region a + c)
  • Namespace A Union B Union C (served by region a + b + c)

Above all, region a/b/c produces namespaces A / B / C / A∪B / A∪C / B∪C / A∪B∪C.  So namespaces are power-set of regions.

There's also the bottom namespace, served by no validators.  Names that are quoted ground terms live in the bottom namespace.

First question: Is the namespace A∪B∪C the root one in the hierarchical namespace tree?

I got impression that namespaces made up a hierarchical  tree. So here A∪B∪C is the root node in that tree, right?

There is a tree, but this isn't where it appears.  The regions form a complete lattice of namespaces; the validators for a namespace are the union of the validators for the component regions.  All validators in a, b, and c have to validate the namespace A∨B∨C.

Second question : How are transactions organized in blockDAG across namespaces?

  • wallet X whose main purse x lives in namespace A.
  • wallet Y whose main purse y lives in namespace B.

Now transfer 1 REV from wallet x to wallet y. I imagine it would happen in following steps 

  1. create a new purse x' and transfer 1 REV from x to x'
  2. transfer purse x' ownership from wallet X to wallet Y
  3. transfer 1 REV from x' to y

Are they correct?

Very close.  There's a subtlety in point 2: ownership of a purse is determined by who has a copy of the unforgeable name the purse is listening on.  It would work something like this.  Alice, who has a coinpurse in A, wants to send 1 Rev to Bob, who has a coinpurse in B.  Let's suppose also that Bob has registered a contract under the URN `rho:pubkey:secp256:bobkey` in B for the purpose of exchanging Rev with parties with whom he has no previous relationship.

  1. Alice creates a new coinpurse x' and transfers 1 Rev into it.
  2. Alice requests the write-only name to Bob's contract: `registry!("lookup", `rho:pubkey:secp256:bobkey`, ret) | for (bob <- ret) { ... }`
  3. In the body of the `for` in step 2, Alice sends x' on the channel `bob`: `bob!("deposit", x', ack) | for (_ <- ack) { <stuff to do once bob has acknowledged the deposit> }`
  4. When Bob's contract receives x', it transfers the 1 Rev from x' into Bob's coinpurse: `@"deposit", @coinPurse, ack => coinPurse!("moveAll", myCoinPurse, ack)`
  5. When x' is done moving Rev to Bob's coinpurse, it sends `Nil` on `ack`.
  6. The body of the `for` in step 3 runs.

Steps 1, 2, 3 occur in A.  When A reaches a state where it cannot roll back the send `bob!("deposit", x', ack)`, it notifies B that a message is waiting for it.  B then includes `bob!("deposit", x', ack)` in a block for B.  When B reaches a state where it cannot roll back the inclusion, it notifies A that the message was received.  A then removes `bob!("deposit", x', ack)` from its state.  Step 4 and 5 happen in B.  A similar two-way notification process happens for the transfer of the send on `ack` from B to A, and then step 6 happens in A.

Note that the inter-namespace notification process is slow, because it has to wait for safety in both namespaces.  If Alice and Bob were going to be exchanging lots of messages, it would make sense for them both to deploy code in A∨B and let those interact a bunch via intra-namespace sends and receives, and then later bundle up everything they need to know and then do only a few inter-namespace interactions.

  • What's important is step #2, it occurs in namespace A∪B and involves both regions a+b, I am curious how it is recorded in the blockDAG's of region a and region b

    • From what I see region b only cares if region a released the ownership while region a only cares if region b acquire the ownership. So they record their own part?
    • namespace A∪B is more like a conceptual namespace and it does not have its own blockDAG?

In the particular case of sending Rev, there's no need for the namespace A∨B, but you're right on the first point: both a and b record on their own chain their portion of the inter-namespace notifications.

You're wrong on the second point, though: A∨B in particular, and every namespace in general, is its own blockdag.  The blockdag in A∨B is validated by the validators in the regions a and b.

 


ReplyQuote
jerry
(@jerry)
Eminent Member
Joined:5 months  ago
Posts: 27
02/05/2018 10:37 am  

Appreciated by @Mike for your explaination.   😀 

every namespace in general, is its own blockdag

I see the attached image in this JIRA page.  https://rchain.atlassian.net/wiki/spaces/CORE/pages/13435265/Blockmumble

The joined namespace (e.g.  AvB), its block's parent refers to block from the underlayer namespace (A and B).  So all the blockDAG sub-chains from each namespace form a big unique DAG chain, do I understand it correctly?

 


ReplyQuote
Mike Stay
(@stay)
Member Moderator
Joined:4 months  ago
Posts: 19
02/05/2018 4:22 pm  
Posted by: jerry

So all the blockDAG sub-chains from each namespace form a big unique DAG chain, do I understand it correctly?

That page is rather old, but yes, that's the idea.  Last week we came to agreement on another layer that I didn't get into above; I'm busy writing up the document now.  In the system above, we have to preserve the invariant that certain names are unforgeable.  To guarantee that each namespace doesn't cheat and forge a name, all the validators not only have to check the Casper data and the Rholang data in their own namespace, they have to trust some coalition of watchers that check the Rholang data that covers the entire network.  Since adding a new region increases the watcher burden on existing validators, this doesn't scale.

In order to scale, we're introducing an "organizational dag", a rooted directed acyclic graph formed by superimposing organizational trees.  The vertices in the operational dag will be independent lattices as described above.  These vertices do not necessarily watch each other, so adding a new vertex to the organizational dag will not impose a burden on any other part of the organizational dag.  This comes at a cost, however: contracts can no longer trust that inputs coming from other vertices have any security invariants at all.  It will be much like the open internet today: contracts will accept only data, not unforgeable names, and will need to be written defensively, i.e. they will need to validate or sanitize any data received from other vertices.

We have design patterns that allow us to track resources like Rev allocated to each subtree, so we can still move Rev around in the tree without needing a central authority, but more general capabilities are harder to use between vertices in the organizational dag because one cannot rely on either secrets or unforgeability.  That said, the organizational dag's security is no worse than any other computational blockchain, and we have the extra security guarantees mentioned above within each vertex.


ReplyQuote
jerry
(@jerry)
Eminent Member
Joined:5 months  ago
Posts: 27
03/05/2018 1:54 am  

I have posted the explaination of namespace from above in another Chinese post. And it attracts attentions in a short time.

For DAG part, I think I'd wait for a bit longer before it becomes more clear . Currently it is still mumble to me 🙂 

Anyway, I get your general idea 🙂 thanks for that 😀 

Looking forward to any new document in JIRA describing the DAG part.


ReplyQuote
  
Working

Please Login or Register