Strange behaviour with bin gossip

Strange behaviour with bin gossip

by Bastien Wermeille -
Number of replies: 9

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,
In reply to Bastien Wermeille

Re: Strange behaviour with bin gossip

by Pasindu Nivanthaka Tennage -

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

In reply to Bastien Wermeille

Re: Strange behaviour with bin gossip

by Peter Krcmar -

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.

In reply to Peter Krcmar

Re: Strange behaviour with bin gossip

by Bastien Wermeille -

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

In reply to Peter Krcmar

Re: Strange behaviour with bin gossip

by Aaron Joos Lippeveldts -

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

In reply to Aaron Joos Lippeveldts

Re: Strange behaviour with bin gossip

by Francesco Intoci -

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

In reply to Aaron Joos Lippeveldts

Re: Strange behaviour with bin gossip

by Cristina Basescu -

Hey Aaron,

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

Thanks for clarifying.

Cristina 

In reply to Cristina Basescu

Re: Strange behaviour with bin gossip

by Francesco Intoci -

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.

In reply to Aaron Joos Lippeveldts

Re: Strange behaviour with bin gossip

by Cristina Basescu -

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 



In reply to Cristina Basescu

Re: Strange behaviour with bin gossip

by Francesco Intoci -

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?