collusion: game theoretical solution with smart contract - golemfactory/golem-rd GitHub Wiki

See collusion: game-theoretical solution without-smart-contract page for the background.

Dumb Evil Contract

Colluding providers may attempt to secure cooperation by enforcing it via some smart contract (Evil Contract). Evil Contract may work like this:

  1. P1 signs following message {RequestorAddr, TaskId, SubtaskId, HashOfJunkResult} and passes it to P2 as a part of black market protocol
  2. P1 submits {SubtaskId, SomeOtherHash} to Requestor
  3. If Requestor publishes signed {SubtaskId, SomeOtherHash} by P1, then P2 submits both first and second messages to the Evil Contract and P1's deposit goes to P2 (assuming that SubtaskId is unique enough)

It is trivial to defeat such contract - Requestor should not reveal to the world information signed by P1.

Smarter Evil Contract (SEC)

We established that one-gets-paid allows to play cheating providers against each other, while both-get-paid does not. One-gets-paid creates a problem where process of choosing whom will get paid should be non-manipulatable by the requestor. This means that it should be public. With this in mind lets try less naive approach. Smarter Evil Contract do its evil deed in following manner:

  1. P1 signs following message {RequestorAddr, TaskId, SubtaskId, HashOfJunkResult} and passes it to P2 as a part of black market protocol
  2. P1 submits {SubtaskId, SomeOtherHash} to Requestor
  3. Requestor sends money to P1. Lets assume that from revealed random number its obvious that P2 should be paid in case when both P1 and P2 has submitted identical results (this is the interesting case). This amounts to implicit fault of P2.
  4. P2 submits fault information (e.g. in form of proof that random number points to P2 and P1 got money anyway). SEC rewards P2 with P1's deposit.

It seems that there is no way to actually hide information while the mechanism that prevents Requestor from choosing from whom to buy the output is in place. Removing this mechanism might be a good tradeoff.

Exploiting the Smarter Evil Contract

Requestor can put sybil Provider into computation. When SP1 and P2 will compute the result, SP1 will receive P2's signature. Next Requestor awards fee to P2. SP1 submits fault information to SEC, SEC rewards SP1 with P2's deposit. This is possible due to P2's inability to prove what value he actually submitted to R (providers should not get recipes).

Actual limitations of Smarter Evil Contract

Due to possibility of Requestor putting sybil Provider into computation, deposit in SEC might not be significantly higher than price of subtask. TODO: more analysis (game-theoretical perspective?; burn deposit instead of taking it over?)

Allowing Requestor to arbitrarily pick provider that will get paid

WIP