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 |
|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.|