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
We use the on-chain aggregation to prevent freeloading attacks with the commit/reveal pattern.
Problem Description
For instance, for some proof, let's say proofA, it needs 10 verifications to decide this proof is valid or not.
Since the commit/reveal pattern needs 2 txs per verification per worker nodes, what if in stage commitment, there are exactly 10 commits submitted while in the reveal stage, there are only 8 reveals(can not reach the threshold).
Then what we are gonna do with this proof-verification task? partly re-open or do it right up from the beginning? The pros and cons for these 2 solutions are quite obvious, partly re-open is not perfectly safe because after it is revealed, the freeloaders then have a chance to cheat. do-it-again is safe but expensive for verification node operators
The text was updated successfully, but these errors were encountered:
Background
We use the on-chain aggregation to prevent freeloading attacks with the commit/reveal pattern.
Problem Description
For instance, for some proof, let's say
proofA
, it needs 10 verifications to decide this proof is valid or not.Since the commit/reveal pattern needs 2 txs per verification per worker nodes, what if in stage commitment, there are exactly 10 commits submitted while in the reveal stage, there are only 8 reveals(can not reach the threshold).
Then what we are gonna do with this proof-verification task? partly re-open or do it right up from the beginning? The pros and cons for these 2 solutions are quite obvious,
partly re-open
is not perfectly safe because after it is revealed, the freeloaders then have a chance to cheat.do-it-again
is safe but expensive for verification node operatorsThe text was updated successfully, but these errors were encountered: