Homework 3 forum

Strange behaviour with bin gossip

 
Picture of Bastien Wermeille
Strange behaviour with bin gossip
by Bastien Wermeille - Monday, 30 November 2020, 17:47
 

Hello,

I'm trying to make some tests pass but I found a strange behaviour with the follwing test :
- TestBinGossiper_No_Contention_Block_TLC_Consensus
This one check that the block added is correct. However, the first block proposed by the bingossiper is not valid.
Indeed, the PreviousHash field should be a 32 []byte as described in the handout but the bin bossiper proposal is a 0 length []byte.

Could it be possible to just check that point, because otherwise I don't see where the problem lies as I never change block when I receive one.
Thanks,
Picture of Pasindu Nivanthaka Tennage
Re: Strange behaviour with bin gossip
by Pasindu Nivanthaka Tennage - Tuesday, 1 December 2020, 11:28
 

Hello,

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.

Regards
TAs

Picture of Peter Krcmar
Re: Strange behaviour with bin gossip
by Peter Krcmar - Tuesday, 1 December 2020, 12:36
 

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.

Picture of Bastien Wermeille
Re: Strange behaviour with bin gossip
by Bastien Wermeille - Tuesday, 1 December 2020, 13:09
 

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

Picture of Aaron Joos Lippeveldts
Re: Strange behaviour with bin gossip
by Aaron Joos Lippeveldts - Tuesday, 1 December 2020, 18:06
 

Can a TA confirm if this is the case? Because I think in the lab session on Friday the opposite was said.

Picture of Francesco Intoci
Re: Strange behaviour with bin gossip
by Francesco Intoci - Wednesday, 2 December 2020, 11:39
 

Actually I think that there is a test which requires Previous Block Hash to be non empty

Picture of Cristina Basescu
Re: Strange behaviour with bin gossip
by Cristina Basescu - Wednesday, 2 December 2020, 12:02
 

Hey Aaron,

I, unfortunately, don't understand your question: what was said in the session, and what does it contradict?

Thanks for clarifying.

Cristina 

Picture of Francesco Intoci
Re: Strange behaviour with bin gossip
by Francesco Intoci - Wednesday, 2 December 2020, 12:11
 

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.

Picture of Cristina Basescu
Re: Strange behaviour with bin gossip
by Cristina Basescu - Wednesday, 2 December 2020, 16:22
 

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 



Picture of Francesco Intoci
Re: Strange behaviour with bin gossip
by Francesco Intoci - Wednesday, 2 December 2020, 16:31
 

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?