Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Dispute Resolution Proposal #4

Merged
merged 22 commits into from Mar 22, 2018
Merged

Dispute Resolution Proposal #4

merged 22 commits into from Mar 22, 2018

Conversation

@hswick
Copy link
Member

hswick commented Mar 8, 2018

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

This comment has been minimized.

Copy link
Member

mrsmkl commented Mar 8, 2018

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

This comment has been minimized.

Copy link
Member Author

hswick commented Mar 8, 2018

@mrsmkl do you mean something like this?

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

    function timeout(uint gameId);
}
@mrsmkl

This comment has been minimized.

Copy link
Member

mrsmkl commented Mar 8, 2018

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

This comment has been minimized.

Copy link
Member

mrsmkl commented Mar 8, 2018

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

This comment has been minimized.

Copy link
Member Author

hswick commented Mar 8, 2018

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

This comment has been minimized.

Copy link
Member

mrsmkl commented Mar 8, 2018

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

@hswick

This comment has been minimized.

Copy link
Member Author

hswick commented Mar 8, 2018

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

@mrsmkl

This comment has been minimized.

Copy link
Member

mrsmkl commented Mar 8, 2018

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

@sinahab

This comment has been minimized.

Copy link

sinahab commented Mar 18, 2018

Man, this is looking really good!

@hswick

This comment has been minimized.

Copy link
Member Author

hswick commented Mar 22, 2018

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

@hswick hswick merged commit 8a40795 into master Mar 22, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
3 participants
You can’t perform that action at this time.