Homework 3 forum
Strange behaviour with bin gossip
Thanks for the question.
Unfortunately, we were not able to reproduce this buggy behavior in our bin_gossiper. If you still believe that there is something wrong in the bin_gossiper, please give additional information so that we can debug further.
We also suspect the following behavior. Are you sending a wrong TLC message, where the block has a 0 length previousHash instead of a 32 length one. The bingossiper will compute its own prevHash and check that it matches the one received in the TLC message. If it doesn’t match. it logs an error: SEVERE: previous hash mismatch
But in any case the bingossiper will use the prevHash received in the TLC message
If this is still confusing, please feel free to ask further with more details, and we are happy to help.
Hey, are you talking about blocks included in PaxosPropose messages or TLC messages? If it's the first one then I believe it's normal, it should be an empty array (probably to make packets shorter) and the PreviousHash field is only added when concensus on a (name,metahash) pair is reached and you send the TLC.
Alright, it's exactly that. As paxos propose some block and not a pair (metahash, filename), I assumed that we directly propose a valid block.
I'll change this behaviour to fit this one but I honestly do not see why we pass a block in Paxos if what we really use is just a string for the filename and a byte for the metahash.
Furthermore, this breaks the encapsulation principle as TLC should not have to communicate with the blockchain to resolve the previous block. It should only have to return the block of the consensus.
Can a TA confirm if this is the case? Because I think in the lab session on Friday the opposite was said.
I, unfortunately, don't understand your question: what was said in the session, and what does it contradict?
Thanks for clarifying.
I think that Aaron was talking about the question I asked you regarding whether the values proposed in the Paxos Algorithm should present a Previous Block Hash value or not, and you answered me that the logical implementation would suggest to include this value from the beginning, and not to add it when plugging the value into the BlockChain.
Furthermore I would also point out another strange behaviour with the Bin Gossiper. In Test 9 Integration I noticed that the BinGossiperA proposing the value will switch the proposed value to a value that has MetaHash = nil, PreviousHash = nil and Filename="".
This value is the one he receives from the promises of my gossipers, that is the empty value the acceptors in Paxos algorithm should return in promises if they haven't accepted yet any other value. I don't know if I am correct.
Answering Aaron's question based on Francesco's clarification (thanks Francesco!).
The short answer is that a node proposing a block to Paxos does not fill in the hash value at the time when it proposes. So the hash field is practically an empty slice. The node will fill in the hash value only when that block reaches consensus, and the hash value will be the hash of the previous block, if such a block exists, or a byte slice with 32 zeros.
My answer on Friday's TA session was that, for the algorithm's correctness, the moment we fill in the hash doesn't matter *when we're dealing with crash-stop failures*. However, it does seem to matter for test assertions, so perhaps my comments were misleading.
As a side note: the algorithm is correct either way because in our attacker model nodes do not misbehave, thus everyone computes the same hash for the blockchain up to some id - regardless of the moment they compute it. If we had Byzantine nodes, that misbehave arbitrarily, consensus *should* include the hash.
I hope this clarifies the issue.
Thanks for the reply. Actually I think that there is a test (need to check which one) that will fail if the Previous Block Hash value is set to nil when starting the Paxos Algorithm. Anyway could you also address my problem in test 9 with the BinGossipers?