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.
Homework 3 forum
Strange behaviour with bin gossip
Re: Strange behaviour with bin gossip
Re: Strange behaviour with bin gossip
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.
Thanks
Re: Strange behaviour with bin gossip
Can a TA confirm if this is the case? Because I think in the lab session on Friday the opposite was said.
Re: Strange behaviour with bin gossip
Actually I think that there is a test which requires Previous Block Hash to be non empty
Re: Strange behaviour with bin gossip
Hey Aaron,
I, unfortunately, don't understand your question: what was said in the session, and what does it contradict?
Thanks for clarifying.
Cristina
Re: Strange behaviour with bin gossip
Hi Cristina,
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.
Re: Strange behaviour with bin gossip
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.
Cristina
Re: Strange behaviour with bin gossip
Hello Cristina,
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?