Skip to main content

Permissions

Permissions: {
  "VerificationKey": {
     "impossibleDuringCurrentVersion": () => VerificationKeyPermission;
     "none": () => VerificationKeyPermission;
     "proofDuringCurrentVersion": () => VerificationKeyPermission;
     "proofOrSignature": () => VerificationKeyPermission;
     "signature": () => VerificationKeyPermission;
    };
  "allImpossible": () => Permissions;
  "default": () => Permissions;
  "dummy": () => Permissions;
  "fromJSON": (permissions: {}) => Permissions;
  "fromString": (permission: AuthRequired) => AuthRequired;
  "impossible": () => AuthRequired;
  "initial": () => Permissions;
  "none": () => AuthRequired;
  "proof": () => AuthRequired;
  "proofOrSignature": () => AuthRequired;
  "signature": () => AuthRequired;
};

Type declaration​

VerificationKey​

VerificationKey: {
  "impossibleDuringCurrentVersion": () => VerificationKeyPermission;
  "none": () => VerificationKeyPermission;
  "proofDuringCurrentVersion": () => VerificationKeyPermission;
  "proofOrSignature": () => VerificationKeyPermission;
  "signature": () => VerificationKeyPermission;
};

Special Verification key permissions.

The difference to normal permissions is that Permission.proof and Permission.impossible are replaced by less restrictive permissions:

  • impossible is replaced by impossibleDuringCurrentVersion
  • proof is replaced by proofDuringCurrentVersion

The issue is that a future hardfork which changes the proof system could mean that old verification keys can no longer be used to verify proofs in the new proof system, and the zkApp would have to be redeployed to adapt the verification key.

Having either impossible or proof would mean that these zkApps can't be upgraded after this hypothetical hardfork, and would become unusable.

Such a future hardfork would manifest as an increment in the "transaction version" of zkApps, which you can check with ().

The impossibleDuringCurrentVersion and proofDuringCurrentVersion have an additional txnVersion field. These permissions follow the same semantics of not upgradable, or only upgradable with proofs, as long as the current transaction version is the same as the one on the permission.

Once the current transaction version is higher than the one on the permission, the permission is treated as signature, and the zkApp can be redeployed with a signature of the original account owner.

VerificationKey.impossibleDuringCurrentVersion()​

impossibleDuringCurrentVersion: () => VerificationKeyPermission;

Modification is impossible, as long as the network accepts the current TransactionVersion.

After a hardfork that increments the transaction version, the permission is treated as signature.

Returns​

VerificationKeyPermission

VerificationKey.none()​

none: () => VerificationKeyPermission;

Modification is always permitted

Returns​

VerificationKeyPermission

VerificationKey.proofDuringCurrentVersion()​

proofDuringCurrentVersion: () => VerificationKeyPermission;

Modification is permitted by zkapp proofs only; as long as the network accepts the current TransactionVersion.

After a hardfork that increments the transaction version, the permission is treated as signature.

Returns​

VerificationKeyPermission

VerificationKey.proofOrSignature()​

proofOrSignature: () => VerificationKeyPermission;

Modification is permitted by zkapp proofs or signatures

Returns​

VerificationKeyPermission

VerificationKey.signature()​

signature: () => VerificationKeyPermission;

Modification is permitted by signatures only, using the private key of the zkapp account

Returns​

VerificationKeyPermission

allImpossible()​

allImpossible: () => Permissions;

Returns​

Permissions

default()​

default: () => Permissions;

Default permissions are:

Permissions.editState = Permission.proof

Permissions.send = Permission.signature

Permissions.receive = Permission.none

Permissions.setDelegate = Permission.signature

Permissions.setPermissions = Permission.signature

Permissions.setVerificationKey = Permission.signature

Permissions.setZkappUri = Permission.signature

Permissions.editActionState = Permission.proof

Permissions.setTokenSymbol = Permission.signature

Returns​

Permissions

dummy()​

dummy: () => Permissions;

Returns​

Permissions

fromJSON()​

fromJSON: (permissions: {}) => Permissions;

Parameters​

• permissions

Returns​

Permissions

fromString()​

fromString: (permission: AuthRequired) => AuthRequired;

Parameters​

• permission: AuthRequired

Returns​

AuthRequired

impossible()​

impossible: () => AuthRequired;

Modification is impossible.

Returns​

AuthRequired

initial()​

initial: () => Permissions;

Returns​

Permissions

none()​

none: () => AuthRequired;

Modification is always permitted

Returns​

AuthRequired

proof()​

proof: () => AuthRequired;

Modification is permitted by zkapp proofs only

Returns​

AuthRequired

proofOrSignature()​

proofOrSignature: () => AuthRequired;

Modification is permitted by zkapp proofs or signatures

Returns​

AuthRequired

signature()​

signature: () => AuthRequired;

Modification is permitted by signatures only, using the private key of the zkapp account

Returns​

AuthRequired

Source​

lib/mina/account-update.ts:278