Fix init()
by removing optional key argument
#908
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
fixes o1-labs/zkapp-cli#406
This removes the optional
zkappKey
argument tosmartContract.init()
For context, this argument was originally added for the case that you make
init()
a@method
, to prove that it was called and to get theprovedState = true
property on the zkapp account.If
init()
is a@method
, it means everybody can call it after deploy (since it doesn't require a signature!). That's bad of course, because we wantinit()
to only be callable once; we don't want everyone to be able to reset the state.The solution to this is to add a precondition on
provedState
: to callinit()
,provedState
must be false. Sinceinit()
causesprovedState
to become true, and assuming that the state is henceforth only updated with proofs, nobody will ever be able to call it again.At the time of introducing
init()
, the proved state precondition was not available. Therefore, as a workaround, we added an optionalprivateKey
argument toinit()
, and made it prove thatprivateKey.toPublicKey()
equals the account's address. With this workaround, only the owner of the zkapp private key could callinit()
(but they could do so as often as they wanted). We no longer need this workaround since theprovedState
precondition is available now.Removing the optional argument also solves a bug that occured when you didn't annotate the optional argument as a
@method
argument, but still passed in the private key. It's not supported to leave out a@method
argument, but the previousdeploy()
behaviour made it extremely easy to accidentally cause such a bug. (see o1-labs/zkapp-cli#406, where the Sudoku zkApp didn't specify the zkappKey argument). In general, optional arguments to a zkApp method are an absolute anti-pattern