Open hswick opened 6 years ago
After this is implemented thinking of forking this for historical purposes.
IMO we should implement this after we have the protocol described in written format, and have had a more rigorous discussion of it's security properties.
Some quick q's off the top of my head:
Let's discuss this on Thursday. I'll send you both calendar invites. Offhand, I can see two risks.
Having a single solution seems to make timeouts more fragile. What's the advantage over two solutions?
Verifiers may decide not to broadcast "no challenge" messages in order to save gas, particularly when tasks are selected at random. This savings results in a telegraphing of solution errors, which leads to a Cartel that only shows up to Challenge errors. Your modification against incorrect secondary solutions fixed this.
Jason
Section 5.4 of the white paper has some relevant context on why the original protocol required the solver to post two solutions. Quoting below:
""" Forced error in disguise. What happens if a Solver has a forced error but gives a correct solution anyway? The Solver could then challenge his own solution while other Verifiers ignore it, resulting in both the Solver receiving a bigger share of the jackpot as well as damage to the system’s verification mechanism. Therefore, when the Solver reveals that a forced error was in effect, the protocol also forces him to reveal his committed “correct” solution which must be distinct from the “incorrect” solution that he showed at first. If the second solution revealed by the Solver is correct and distinct from his first solution, then by uniqueness of deterministic processes, the first solution must have been incorrect (as desired). """
We should keep this in mind for this design.
Right! That's why we had two solutions. The more obvious protocol with one solution didn't work.
In the implementation where solver only submits one solution the solver never submits an "incorrect" solution. The task giver just has to resend the task. This means the Forced error in disguise issue never comes up.
Forced error is determined only after solver and verifiers have bonded stake to the contract.
The single solution implementation isn't secure. The Solver could submit a correct solution during a forced error.
I'm not understanding how a solver could submit a correct solution during a forced error if the forced error happens after the solution submission?
If the Solver submits only one solution, it could either be either correct or incorrect regardless of whether there's a forced error. @sinahab's comment above explains the Solver's incentive for intentionally submitting a correct solution during a forced error.
Christian suggested this change to truebit classic during dev call.
This changes protocol by not needing a second incorrect solution submitted.
Solver only submits the hash of the solution they stake is correct.
Verifiers will submit hash of intent (even or odd) if challenging or not. Then challengers will be committed to task.
After solver and verifiers commit, forced error is determined. This incentivizes verifiers to actually challenge because of the chance of a jackpot.
In case of forced error, jackpot payout and task giver submits task again. This is acceptable because probability of forced error is assumed to be very low.