add txnVersion to verification key permission #1208
Conversation
| }, | ||
| "approveRegistrations": { | ||
| "rows": 1146, | ||
| "digest": "197ce95e1895f940278034d20ab24274" | ||
| "rows": 1147, |
There was a problem hiding this comment.
I am actually a bit surprised by this change - this change shouldn't impact this as far as I understand, but maybe something on the Mina branch changed how snarky works 🤔
There was a problem hiding this comment.
the new transaction version becomes part of the hash input when hashing the account update. since the constraints don't change by a lot, it seems the number of poseidon rounds doesn't increase, but what does increase potentially is the number of operations for packing the new UInt32 into the field elements that are hashed (well only if the addition is not part of a chain of added constants already).
Also, every new constant adds half a row. We probably didn't use the constant 3 before in this circuit. I think this is what causes the constraint increase in most of these methods
🤓
There was a problem hiding this comment.
Thats right! Didnt think about that at all
| }, | ||
| "approveRegistrations": { | ||
| "rows": 1146, | ||
| "digest": "197ce95e1895f940278034d20ab24274" | ||
| "rows": 1147, |
There was a problem hiding this comment.
the new transaction version becomes part of the hash input when hashing the account update. since the constraints don't change by a lot, it seems the number of poseidon rounds doesn't increase, but what does increase potentially is the number of operations for packing the new UInt32 into the field elements that are hashed (well only if the addition is not part of a chain of added constants already).
Also, every new constant adds half a row. We probably didn't use the constant 3 before in this circuit. I think this is what causes the constraint increase in most of these methods
🤓
o1js implementation of the protocol change described by this RFC
This change enables developers to flag contracts as immutable but not prevent them from deadlocking with future protocol changes. In addition to the permission type a developer wants to specify for
setVerificationKey, it is now possible to also specify atxnVersion: UInt32which will be stored on-chain as part of the zkApp accounts permission field. If thetxnVersionmatches the current protocol version, permissions of typeProofandImpossibleact normal. If thetxnVersionis older than the current protocol version, the permission falls back toSignatureautomatically, so that now broken smart contracts can be upgraded using a Signatures.TODO: docs MinaProtocol/docs2#750
companion of MinaProtocol/mina#14407
bindings o1-labs/o1js-bindings#195