You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I have been puzzling over the Merkle tree re-construction done in RBC. Once a node gets N-F Echo or Val messages with the same root hash H (and the associated merkle proofs), assuming all those proofs are validated, what does re-creating the Merkle tree and comparing the root hashes get you?
If you have N-F merkle proofs that you've validated that all agree on the same root hash isn't the chance of re-assembling the shards not matching the original message slim to none? Re-hashing the merkle tree (on every peer) for each of N RBC instances gets pretty painful when N is large.
I think this is for the case of a faulty sender: If the sender uses shards that aren't actually part of an erasure coding to create an otherwise valid Merkle tree, then all the proofs you receive are valid. But interpolation would produce different values, and you would compute a different root hash.
I have been puzzling over the Merkle tree re-construction done in RBC. Once a node gets N-F Echo or Val messages with the same root hash H (and the associated merkle proofs), assuming all those proofs are validated, what does re-creating the Merkle tree and comparing the root hashes get you?
If you have N-F merkle proofs that you've validated that all agree on the same root hash isn't the chance of re-assembling the shards not matching the original message slim to none? Re-hashing the merkle tree (on every peer) for each of N RBC instances gets pretty painful when N is large.
cc @madninja
The text was updated successfully, but these errors were encountered: