-
Notifications
You must be signed in to change notification settings - Fork 1
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
First version of Authz TLA+ #2
Conversation
I had a high-level look at the model. Let me write preliminary comments as the basis for the synchronous discussion tomorrow. First thing to say, I am very impressed by how well structured and easy to read it is. It is also extremely modular. I also notice that the model very much follows the code structure. I can see an advantage being that the developers of the implementation would have an easier time following along the model.
Finally, a very high-level question: when you were looking at the existing model, what made you decide to start from scratch? |
Test scenarios
I just noticed one thing in the Cosmos-SDK codebase: they are also adding the |
[] auth.authorizationType \in Stake!MsgTypeUrls -> | ||
Stake!MsgTypeURL(auth) | ||
|
||
Accept(auth, msg) == |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It seems that this way of modelling Accept
prevents send
or stake
messages that rely on a generic authorization. Is that true?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
GenericAuthorization
accepts any kind of message url, including send
or delegate
, for instance. The accepted messages are defined in the constant GenericAuthTypes
. So one could instantiate this constant with any kind of message (I haven't tried it).
If it's the same as in the Staking module, it should be easy to change. Good to know anyway. |
I added to |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The model is great! Very well structured, and logical. I have made some comments about potential improvements for using the model for test case generation, but those can be addressed separately later.
/\ IsValid(g) | ||
/\ ~ HasGrant(g) \/ IsExpired(g) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
My feeling is that the way RequestGrant
and other top-level operators from Next
are too restrictive for testing purposes. In particular, we want to be able to test inputs where:
granter
is the same asgrantee
- there is already a grant given, and it's not expired
So, in short, we should treat the inputs maximally non-deterministically, and ensure that the implementation fails for incorrect combinations of input parameters.
/\ IsValid(g) | ||
/\ HasGrant(g) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Same as RequestGrant
above
\* https://github.com/cosmos/cosmos-sdk/blob/c1b6ace7d542925b526cf3eef6df38a206eab8d8/x/authz/authz.pb.go#L74 | ||
\* @typeAlias: GRANT = [authorization: AUTH, expirationTime: EXPIRATION_TIME]; | ||
\* @type: Set(GRANT); | ||
Grants == [ | ||
authorization: Authorization, | ||
expirationTime: ExpirationTimes | ||
] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Type AUTH
is defined in each of Generic
/Send
/Stake
Autohrization
separately; and then it is used in Grants here. It is unclear which AUTH
is used; in fact Apalache's type checker should have complained about having multiple type aliases with the same name
Closes #1