Batch hash #932
Batch hash #932
Conversation
iris-mpc-gpu/src/server/actor.rs
Outdated
| let mut valid_merged = vec![false; max_batch_size]; | ||
| for i in 0..self.comms[0].world_size() { | ||
| for j in 0..max_batch_size { | ||
| valid_merged[j] &= results[i][j] == 1; | ||
| } | ||
| } |
There was a problem hiding this comment.
Should we still keep this or fail? seems if we remove some entries than we risk them not being the same signupIds?
There was a problem hiding this comment.
But this can happen all the time. A client can even force this by sending us a wrongly encrypted share.
There was a problem hiding this comment.
This code has been there actually also before, just slightly rewritten, I can also restore the old version
iris-mpc-gpu/src/server/actor.rs
Outdated
| let mut valid_merged = vec![false; max_batch_size]; | ||
| for i in 0..self.comms[0].world_size() { | ||
| for j in 0..max_batch_size { | ||
| valid_merged[j] &= results[i][j] == 1; |
There was a problem hiding this comment.
Given that we first set everything to false and then we apply &= operation, wouldn't it always resolve to false - no matter what rhs (results[i][j] == 1) is? 🤔
There was a problem hiding this comment.
you're right, and this also shows an issue with our e2e tests. Since this means we don't return any results, there are no mismatches.
Calculates a hash out of the signup ids of the current batch and syncs this hash across the node. This makes sure the queues are actually in sync before starting processing. This just throws an error and the actor can't recover it on its own requiring manual intervention.