When - Thursdays at 14:00 UTC
Where - This meeting takes place online using Zoom
- Join from PC, Mac, Linux, iOS or Android: https://zoom.us/j/134156866
- Or iPhone one-tap :
  US: +16468769923,,134156866# or +16699006833,,134156866#
- Or Telephone:
      Dial(for higher quality, dial a number based on your current location):
          US: +1 646 876 9923 or +1 669 900 6833
      Meeting ID: 134 156 866
      International numbers available: https://zoom.us/u/rDfBtpt
Additional communications are posted in #node-testing on the RChain Discord.

What you can expect this week

Today we discuss questions related to consensus.

Questions	Responses
1. Imagine user want to send some REV to 2 friends and simultaneously deploy sends to first friend to validator A and to second friend to validator B. Validators propose simultaneously. How will validators figure out transfer sequence? Will resulting balance of sender be lowered by sum of transactions? Can there be the case when this tx sent to different validators are considered as duplicating?	Discussed during session.
2. Is there some Casper-related work made by node during the process of propose? More broad - what events trigger Casper to do its work? Block receive? Propose?	Discussed during session.
3. If node has lots of incoming blocks in queue, is it allowed to evaluate new deploy and propose new block before it write all changes from new blocks into its tuplespace?	Dan Connolly yes, I think a validator can pick and choose which deployments to run, much like BTC or ETH nodes can choose which transactions to put in a block -- those that pay more are likely to get more attention. I don't think rnode as written does any of that, though
4. I assume that all changes to tuplespace are written when rnode executes deploy content. Is this valid? Can node be wrong and ought to make changes to values written in rspace when all other nodes come to agreement on value that is different?	Dan Connolly yes, a node can be "wrong" in the sense that its proposal isn't the one that wins that round of casper
5. Why should node execute deploy twice?	Dan Connolly I'm not sure, but I think the current rnode evaluates a deploy once to produce a block and then again to consume the block.
6. Can there be situation when there is no certainty about DAG state at the moment? Can this cause node to stuck and no propose?	Dan Connolly yes, there can be unfinalized blocks. I don't think there's anything that can cause any individual node to get stuck, but it's possible for the network (shard) as a whole to get stuck; casper doesn't guarantee liveness. ("FLP impossibility" is a result that says it's impossible to guarantee both safety and liveness). CBC casper has "tuneable liveness" I gather. Greg discusses this at some length in Recent RCast episodes ("living systems" I think)
7. What happens when node receives block again (key point - again)? Does it evaluate its content again? Rebroadcast to other nodes? Or just drop?	Dan Connolly dups are dropped... maybe even slashed. I'd have to read the code again.
8. I can see traces of my past deploy execution again and again in logs - what does fire up this repeatable executions? Is it node received block again or smth else?	Dan Connolly looks like a bug to me Former user (Deleted) Sounds like the block is getting orphaned and so the deploy is being reincluded in the about-to-be-proposed block. A block is orphaned if it is never possible to be finalized. It is part of the protocol Dan Connolly so... having it show up again and again is annoying, maybe, but not incorrect? (a little bit like lack of garbage collection) Former user (Deleted)Just think of it from the perspective of a user. Alice submits a transaction to the network and it gets included into a block A. There is a fork in the chain and block A becomes orphaned. Should Alice resubmit their transaction? nutzipper On test net, let’s say I listen to logs on node7. I can see there traces of execution of past deploys that were in blocks proposed by every node, from node0 to node9. Not just node7. Node7 shouldn’t propose code that was submitted to another validators, isn’t it? Former user (Deleted) Node 7 needs to replay them to get to the same state
9. What is block finalization? Is this something consensus related?(edited)	Dan Connolly yes, block finalization is consensus related. I'm fuzzy on the details, though.
10. When can dApp developer (wallet e.g,) say that transactions is “written on blockchain” and nothing conflicting this TX can influence its result? Like in blockchains people look at how much blocks are added after transactions and make decision.(edited)	Dan Connolly that's what finalization is all about. Again, I'm fuzzy on the details.
11. If node included block into its DAG, can it remove it later and reorganise DAG? Whats block merging?	Dan Connolly removing a block that a node already agreed to is equivocating, I believe. It gets you slashed. I'm fuzzy on block merging. something about the way blocks whose namespaces don't intersect can go in any order. (but practically, all deploys have to touch the registry and the casper wallet, so I don't see how this can actually be exploited in practice)
12. This question is similar to 8, and tied to 10. After deploying lots of transactions using each validator, I run balance check on a single wallet that is recipient. As in Q8 I found that balance check log appearing on my screen again an again - and balance was 0,2,0,2,2,2,2,0, etc. Values do not matter but I saw that once balance was increased due to node executed some deploy with incoming transfer, it reverted it back (more in RCHAIN-3469). With understanding that block with this deploy may be orphaned and node responsible for this deploy have to push it to the network again, this make sense for me now. And looks like after some time (quite long though) network finally converged to final values. But it looks like Ed's wallet ceased to operate while network was trying to converge. So my question is - can this be considered as an attack vector? One can simultaneously deploy transaction which involves changes to a name to each validator (which is exactly what I am doing actually) making network producing lots of orphaned blocks.	Discussed during session.

Share your experience

You best support the improvement and development of the RChain platform when you file a bug to report challenge you faced or unsuccessful outcomes. This will help us collect all relevant information to better understand your setup and experience.

Work completed since the last testing session

key	summary	type	updated	status	resolution

Loading...

Refresh

Testing session summary

We discussed the questions above. Please see recording for responses.

Chat log

Bugs filed

key	summary	type	created	updated	due	assignee	reporter	priority	status	resolution

Loading...

Refresh

Participants

Kent
Chris
Nuttzipper
Joshy
Christian
Steve
Łukasz

RChain wiki

20190605 RNode community testing

Table of contents

Overview