The default permission setup might make it impossible to ever upgrade the token contract

[Comdex]

The default permission settings of the current token standard contract are configured this way:

mina-fungible-token/FungibleToken.ts

Lines 73 to 77 in 7f2427a

	this.account.permissions.set({
	...Permissions.default(),
	setVerificationKey: Permissions.VerificationKey.impossibleDuringCurrentVersion(),
	setPermissions: Permissions.impossible(),
	access: Permissions.proof(),

The access permission is set to Proof, and if I am not mistaken, this requires the corresponding AccountUpdate of the token contract to include a proof in order to be accepted by the network. However, the permission for setVerificationKey will change to Signature after the protocol upgrade. This means that updating the VerificationKey will require signature authorization. Since an AccountUpdate cannot simultaneously include both proof and signature authorization, and with updates to permissions being disallowed, this would likely result in the token contract being permanently unupgradable.

The access permission has the highest priority, which means that when it is set to Proof, other permissions set to Signature will become invalid

[L-as]

This is a very good point.

[L-as]

Unless I’m missing something this isn’t fixable and is a limitation of Mina.

Linked pre-MIP is relevant.

access permission needs to be ignored in some cases or you could split it into two permissions

[Comdex]

Unless I’m missing something this isn’t fixable and is a limitation of Mina.

I think that makes sense. We’ll probably need to make some changes at the protocol level to fix this.

[mitschabaude]

DAMN that's a great find @Comdex. I agree it needs a protocol-level fix.

@mrmr1993 @nholland94 hope you saw this -- once there is a vk-breaking hard fork, all contracts with access=proof are broken, because the verification key update (using a signature) can't go through, and neither can any proof for the outdated vk

[andrewferrone]

Is a short-term workaround to change the access permission to Signature? @kantp

[kantp]

With access set to signature, other things would stop working, so unfortunately we can't do that. I think what we need to do is have a method that changes the verification key, using a proper access control (like what @dfstio is working on for the NFT standard). Then, we need to change the permissions to change the verification key to proof, instead of impossibleDuringCurrentVersion.

[kantp]

Unfortunately, we can't set the permissions to change the verification key to proof with the contract as it is right now, because the updateVerificationKey() method does not control who calls it. So we need to change that, and only then change the permissions.

[kantp]

For anyone following this: there is also a discussion on Discord, see https://discord.com/channels/484437221055922177/1311633212769960009/1311633212769960009.

At the moment, we're trying to get a short term solution to this for the fungible tokens, while also looking at the necessary protocol changes to fix the root cause. I'll update as we progress.

[mrmr1993]

We've been tracking this issue for a while on the O(1) side. There's an easy fix, and it's part of the plan for the next hard fork.
Feel free to use the access permission however you need, the upgrade mechanism will handle it in a coherent way.

[kantp]

Thanks @mrmr1993, that's good news!

What I still want to change is adding access management to the updateVerificationKey method, in order to enable making the contract upgradable before a breaking change to the protocol. That way, people can upgrade to keep up to date with fixes and improvements in o1js.

[kantp]

What I still want to change is adding access management to the updateVerificationKey method, in order to enable making the contract upgradable before a breaking change to the protocol. That way, people can upgrade to keep up to date with fixes and improvements in o1js.

See #113.

[kantp]

With #113, deploy() now has a flag allowUpdates to switch between upgradable and not upgradable (during the current protocol version). The documentation recommends allowing updates during the current protocol version. Updating the verification key requires a permission from the admin contract, so that is customisable (the example contract uses a signature from the admin).

Together with @mrmr1993's message above that the access permission issue will be fixed with the next protocol update, I think we can close this issue.