TrueBitFoundation / dispute-resolution-layer

[DEPRECATED] Generic dispute resolution layer for Truebit verification games
MIT License
6 stars 10 forks source link

Dispute Resolution Proposal #4

Closed hswick closed 6 years ago

hswick commented 6 years ago

Turns out an interface for dispute resolution doesn't make as much as sense. Decided that a BasicVerificationGame contract was more effective at generalizing behavior and usability.

The BasicVerificationGame uses a IComputationLayer interface so any kind of computation layer can be plugged in. That computation layer is then implemented, in this case it is implemented by SimpleAdderVM.

TODO: Add require restrictions for different steps Implement timeout Generate an actual merkle proof Change id from uint to bytes32 Add batch query/response

Above todo's are mostly around taking code from scrypt-interactive and moving it over here

mrsmkl commented 6 years ago

Looking good. Also might be a good idea to have a more general interface for disputes, so that the verification game is not visible at all. That way it will be possible to spawn a chain of different kinds of disputes. So there would probably just be interface methods for timeout and querying about result.

See https://github.com/TrueBitFoundation/webasm-solidity/blob/master/contracts/interactive2.sol#L19 for example.

Using something like this, it should be easy to integrate something like "submitting phases" that my verification game has.

hswick commented 6 years ago

@mrsmkl do you mean something like this?

interface IDisputeResolution {
    function query(uint gameId, uint stepNum);

    function timeout(uint gameId);
}
mrsmkl commented 6 years ago

I meant that there should be a mechanism for querying the result of the dispute, like

// enum State { Unresolved, SolverWon, ChallengerWon }
function status(bytes32 id) returns ( /* State */ uint8);
mrsmkl commented 6 years ago

For ids, should we use uint or bytes32. And should we have the id be the hash of the verification parameters to prevent replay attacks?

hswick commented 6 years ago

Can interfaces use types like that? I feel like that would have to be inherited.

bytes32 makes more sense, uint was easier to implement for proof of concept. I'll fix that

mrsmkl commented 6 years ago

Yeah, interfaces cannot have enums for some weird reason. I updated it to what I meant.

hswick commented 6 years ago

I see. So the idea is that the only thing exposed to something like an incentive-layer would be this status method?

mrsmkl commented 6 years ago

Yeah. Perhaps they could have something to create a new disputation also.

sinahab commented 6 years ago

Man, this is looking really good!

hswick commented 6 years ago

This isn't perfect, but I believe it is at a state where others can collaborate