[RFC] Verification key permissions #13994
Conversation
|
This is an excellent write-up @nholland94! |
| When the `txn_version` referenced by either of these new permissions matches the current hard fork version of the protocol, the permissions act exactly like their normal counterparts (`Proof` fields can only be updated with a valid proof, `Impossible` fields can never be updated). When the `txn_version` is older than (less than) the current hard fork version, then both of these permissions fallback to the `Signature` case, so that the now broken zkApps can be updated for the new hard fork. | ||
|
|
||
| An account permission that is set to either of these new permissions can be updated when the `txn_version` referenced is older than the current hard fork version. This scenario ignores restrictions by `set_permission`, and operates as if `set_permission` were `Signature`. |
There was a problem hiding this comment.
In the scenarios where the txn_version is older (less than) the current hard fork version, is there a risk in the zkApp's centralisation if it can only fall back to the Signature case? I suppose in some scenarios zkApp developers may allow users to participate in a vote, which could act as a Signature but might indeed be a Proof. Grateful for your thoughts!
There was a problem hiding this comment.
Unfortunately, if the release is not backwards compatible with the older proof system, we are not able to accept Proof authorizations since we cannot recursively verify it inside of the transaction snark. In the world where we don't have a backwards compatible upgrade, Signature is the only authorization which would still be valid.
|
|
||
| NB: This RFC relies on the [protocol versioning RFC](TODO). | ||
|
|
||
| In order to prevent a zkApp from breaking upon a future incompatible upgrade of the protocol, we will not allow users to set the `Impossible` or `Proof` permissions on the verification key. Instead, we will add 2 new permissions, `Impossible_during_hard_fork` and `Proof_during_hard_fork`, each of which will carry a specific transaction logic version to represent the hard fork they in which they are valid. Thus, the total set of permissions allowed to be set on verification keys would be: |
There was a problem hiding this comment.
Do we need new permissions? In theory, this creates more unreachable states. I would prefer if we simply check the zkapp_version in the account and fall back to signature when it's not equal.
There was a problem hiding this comment.
Hmm... having these explicit permissions is useful in the UX context, as it makes the choice very clear. Perhaps this can be handled only externally, and the internal implementation is exactly how you suggest it. Let me think on this some more and get back to you.
| ## Drawbacks | ||
| [drawbacks]: #drawbacks | ||
|
|
||
| ## Rationale and alternatives |
There was a problem hiding this comment.
An alternative that we discussed was handling this at the application layer. In particular, if we commit to supporting zkApps at the current version (potentially via an adapter) for at least 1 more version, we can
- expose the zkApps version of an account to the predicates
- add a default rule to all o1js contracts that can reset the permission to signature using a proof
- this also allows the o1js developer to customise the conditions under which an upgrade may be performed (e.g. multisig, etc.)
- leave the permissions as they were in the original design.
|
!ci-build-me |
|
!ci-build-me |
|
!approved-for-mainnet |
|
!ci-build-me |
No description provided.