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

Check game-theoretic safety properties #159

Open
fare opened this issue Aug 15, 2019 · 3 comments
Open

Check game-theoretic safety properties #159

fare opened this issue Aug 15, 2019 · 3 comments

Comments

@fare
Copy link
Contributor

fare commented Aug 15, 2019

The main advantage of our approach over that of other people who use formal methods to verify smart contracts is that we have this explicit notion of multiple participants, out of which we can extract game-theoretic safety properties for each participant, that are not expressible in participant-agnostic formalisms. Let's make sure we prove at least some such properties for RPS and have a way to express them explicitly if we cannot derive them fully implicitly.

@fare
Copy link
Contributor Author

fare commented Sep 16, 2019

The possible? and eventual? predicates in an @A block, or a variant thereof, should be adversarial: it should take into account the fact that B will actively try to make it not happen.

@fare
Copy link
Contributor Author

fare commented Sep 16, 2019

Do something with the correct quantifiers for now. See #166 for the next level.

@fare
Copy link
Contributor Author

fare commented Sep 16, 2019

Also, Jay's fair_game predicates are extremely round about. Hopefully, it should be possible to say at a point before A choses his hand something like possible? (outcome == A_WINS), which either assumes the content inside possible? is all-seeing of the bindings at the end of the interaction, or we have an explicit label feature and COMEFROM feature such that we can express possible? END(outcome == A_WINS) at the point where we assert it's a possible future.

Then there's the matter of the quantifiers: existence with or without a winning strategy, against or not against the other participant's winning strategies.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant