20190605 RNode community testing
Table of contents
Overview
Each week we invite community members to help test RNode.
- 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.
| 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 |
| 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. |
| 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 |
| 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. |
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.
Testing session summary
We discussed the questions above. Please see recording for responses.
Chat log
Bugs filed
Participants
- Kent
- Chris
- Nuttzipper
- Joshy
- Christian
- Steve
- Łukasz