TrueBitFoundation / incentive-layer

[DEPRECATED] Incentive layer contracts and deployment information.
31 stars 20 forks source link

Solver should submit only one solution #25

Open hswick opened 6 years ago

hswick commented 6 years ago

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.

hswick commented 6 years ago

After this is implemented thinking of forking this for historical purposes.

sinahab commented 6 years ago

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:

teutsch commented 6 years ago

Let's discuss this on Thursday. I'll send you both calendar invites. Offhand, I can see two risks.

  1. Having a single solution seems to make timeouts more fragile. What's the advantage over two solutions?

  2. 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

sinahab commented 6 years ago

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.

teutsch commented 6 years ago

Right! That's why we had two solutions. The more obvious protocol with one solution didn't work.

hswick commented 6 years ago

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.

teutsch commented 6 years ago

The single solution implementation isn't secure. The Solver could submit a correct solution during a forced error.

hswick commented 6 years ago

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?

teutsch commented 6 years ago

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.