Disprove execution #142
Disprove execution #142
Conversation
| *result = Rc::new(Box::new(dummy_element( | ||
| &result.id(), | ||
| hash_map.get(result.id()).unwrap().clone(), | ||
| ))); |
There was a problem hiding this comment.
Can't you return when you find the first incorrect param or result? Why go on with the correct hash?
There was a problem hiding this comment.
This function is used when the operator has released all intermediate state hashes, and a segment will first check bit commitment and then run the chunk. So for the inconsistent result, it needs to replace all inconsistent results to make sure that the bit commitment check can pass.
The incorrect param is useless, because we don't know the behavior of segment with incorrect params. But, we can always find the segment containing correct param and incorrect result, because of the continuity of verify algorithms (a input of a segment must be an output of another segment).
There was a problem hiding this comment.
I see. So the verifier is supposed to create its own assigner by executing the segments without the Winternitz part and retrieve the hashes that way. Then they can check for errors in the bit commited hashes from the operator. Do I understand that correctly?
There was a problem hiding this comment.
Yes, you're right. A different type of assigner is needed as a challenger. Running the chunk one by one is another obvious solution, but I think this way is more efficient.
|
I think if we use |
wz14
force-pushed
the
disprove_execution
branch
from
e38644b to
c0d39be
Compare
|
Fix repeated variable name BitVM/src/chunker/chunk_scalar_mul.rs Lines 73 to 79 in c00a487 |
* finish * add test * fix test * remove unuse unit test * fix typo * clean todo and panic * fix bug
2 participants
This PR offers a function to find which chunk is available when the operator did some malicious thing. This function re-runs chunker using the wrong proof to get a wrong-proof assigner, then checks the inconsistency between the wrong-proof assigner and the assigner recovered by assert transaction.
There are two cases a malicious operator can do.
test_wrong_proof.parameteris the same as inresultis different intest_wrong_proof_and_modify_intermediates.