Namespace and consensus  

  RSS

Jerry
(@jerry-2)
Active Member
Joined:2 months  ago
Posts: 6
18/05/2018 3:22 pm  

As I understand,  the rholang execution actually transforms the names stored in tuplespace from one state to another state

e.g.

At a certain point, tuplespace is in state S1 = { A1, B1, C1 }.   
where

  • A1 is the state of name a, which holdes processes or continuations.
  • B1 is the state of name b, which holdes processes or continuations.
  • C1 is the state of name c, which  holdes processes or continuations.

After execution for a while, tuplespace is transformed into state S2 = { A1, C2, D1 }
where 

  • A1 = A1, which means no change on name a during execution
  • B1 has gone, which means name b was consumed and now it holds nothing
  • C1 -> C2, which means name c changed. Maybe new process appended or continuation consumed during execution
  • D1 appears, which means this is a new name d generated during execution

 

First, do I understand correctly?

I have the following questions basing my understanding.

Suppose there is a region R which hosts a standalone(not jointed) namespace X.
Within this namespace, there are multiple validators, which hold the tuplespace.

  1. All validators in R run the same code, right?
  2. Does validators in same namespae have the same content(state) of tuplespace?
    I assume they should have the same copy of tuplespace. Right?
    What I cant understand are:
    • Messages can be delayed, there could be minor differences in tuplespace between validators.
    • Rholang execution is nondeterministic. e.g chan is a name holds more than one messages. for(x <- chan) may consume the first message in one validator but the same code in another validator consumes a different message .  Which results in different result.

    It seems to be just impossible to keep tuplespace in same sate in the same validator.

  3. But if the tuplespace state is different across different validators in X, how could they make a consensus?
  4. What is actually stored into the block?  Or what does a block in this case contain?
    1. changes of tuplespace state?
    2. snapshot of tuplespace state?
    3. hash?
    4. Other?

Best Regards


ReplyQuote
MichaelBirch
(@michaelbirch)
Member Moderator
Joined:4 months  ago
Posts: 33
18/05/2018 4:50 pm  

In Rholang processes are immutable in the sense that any changes that could occur (like adding a new process in concurrent composition or comm rule reduction) actually yield a new process as opposed to modifying the old one. Names are immutable in the same sense because names are quoted processes. That being said, your questions are still valid because which names/processes are stored in the tuplespace does change as Rholang code executes because processes are created and destroyed through comm rule reductions and new code deployments. 

As you point out, is it non-trivial for all the validators to agree on a single state of the tuplespace, but that is why we have a consensus protocol. If they follow the protocol then eventually they will reach consensus (at least in practical situations that is true, technically that is a property called "liveness" which is not a property possessed by any deterministic consensus protocol in an asynchronous setting, by FLP impossibility). To learn how this works you can read more about CBC Casper, which is the general consensus framework we are applying to RChain, here.

In sort though, we are following the description in Vlad's paper, but with an extension to allow blocks with multiple parents. Blocks contain the new code that was deployed in that block, a trace of the execution that occurred after adding that new code (which includes specifying which names were consumed in `for`s, thus solving the issue you pointed out above), and the hash of the final tuplespace state. This makes the computations performed by one validator fully reproducible by other validators when they receive the block.


ReplyQuote
Jerry
(@jerry-2)
Active Member
Joined:2 months  ago
Posts: 6
19/05/2018 12:30 am  

Thanks @MichaelBirch

 


ReplyQuote
  
Working

Please Login or Register