Validator Created Challenges Question

[anthonyra]

After reviewing the code I have a few questions but first I'll try and explain my current understanding of what is happening to see if it's more conceptual error followed by poor code review...

1. The validators create poc_keys based on the challenge rate and number of CG members. These are submitted via heartbeats
2. All validators store their local poc_keys including the secrets. They also store the public poc_keys which are considered poc_key_proposals from all of the other validator's heartbeats
3. While in CG each member uses this cache of keys from the heartbeats then shuffles their list then removes CG members, and submits it via the block metadata to hbbft.

At this step here lies my question or confusion. What ensures the integrity that the metadata matches across all of the members?

The metadata created here,

miner/src/handlers/miner_hbbft_handler.erl

Line 369 in 9df419c

Metadata = lists:map(fun({Id, BMap}) -> {Id, binary_to_term(BMap)} end, Metadata0),

I believe gets passed to hbbft > acs > rbc > bba?

acs
https://github.com/helium/erlang-hbbft/blob/800104fa32d373e5767adbd52c2f9867d951733b/src/hbbft.erl#L206
rbc
https://github.com/helium/erlang-hbbft/blob/800104fa32d373e5767adbd52c2f9867d951733b/src/hbbft_acs.erl#L87
bba
https://github.com/helium/erlang-hbbft/blob/800104fa32d373e5767adbd52c2f9867d951733b/src/hbbft_acs.erl#L110

If this is the case, where does the comparison occur? I've seen mention of using a merkerl tree and hashes but I'm curious on how this will result in the same results? The keys are shuffled, so each members metadata should have a shuffled list of keys. So each list of keys needs to be verified to be equal right?

It appears that only the leader starts an RBC which would make me think that the metadata is that from the leader alone? There are checks to see if the shards equal but the shuffle before metadata submission still concerns me. (I'm probably missing something)

[meowshka]

@anthonyra we’re moving existing issues to the Discussions board. While the original issue will be closed, it will be open and available for collaboration in the Discussions board.