Strategy to reduce conflicts between sibling blocks  

  RSS

jerry
(@jerry)
Eminent Member
Joined:9 months  ago
Posts: 31
12/07/2018 6:19 am  

Within a single namespace, besides optimizing throughput (speed reducting rholang terms) of a single RhoVM, the key to maximize overall throughput of namespace is to maximize degree of parallelism of blocks appended into DAG chain.

The block wraps the state changes in tuplespace resulted by rholang reduction. Sibling blocks generated by individual validators can only be selected as parents of following block when sibling blocks contain indenpendent state changes.

Thus, the key to maximize overall throughput is to reduce conflicts between sibling blocks, namely, sibling blocks avoid to include changes on the same name with each other. Do you think so?

So, what strategy could RChain use to reduce conflicts between sibling blocks?

From what I see,  the end-users' names, like their wallets, are not a problem. 
-- They don't change often; When end-users perform operations, they usually connect to a fixed validator at a time.

What worries is the names(states) in contract. e.g. Some contract may change certain name everytime when it is called.
Hence I have the following ideas

  • Is it better to avoid different contracts depend on the same name internally?
  • Is it better to ensure an individual contract is processed by a fixed validator?
    e.g. validator forwards request via consistent-hashing algorithm to other when the target contract is not belongs to itself.

 

Another strategy might be smaller blocks. If block includes less names whose states changed,  the probability of confliction drops. But this comes with another question: Does RChain allow a contract call distributed multiple-blocks?
e.g. a contract call would results in state changes of names a/b/c in sequence order.  state changes(a & b) are wrapped in first block; state change(c) is wrapped in 2nd block. theoretically this is ok but I dont know its impact on phlogiston. What if the contract execution run out of phlogiston on executing changing name c.

 

I create this thread for open discussion. 

 


ReplyQuote
  
Working

Please Login or Register