tepid scarab
Most likely I'm trying to upgrade verification key in the wrong way but I tired few ways and always end up same as on the screenshot. What is the correct way to do so?
Regardless the above, it seems kinda odd that 'counter' returns different value when zkapp and zkappV2 have exactly the same address.
trying to manually set counter doesn't fail but neither is updating any of the counter as seen on screenshot, odd again
(if I set counter via function on V2 it works)
visual iron
Hi Karol. Is it possible that you have not waited long enough for the V2 counter state to get updated? The transaction presumably needs to be written to a block before the update happens.
tepid scarab
happening on LocalBlockchain, if it wouldn't get included in block then presumably the counter v2 should not come back with anything ? going to try on Berkeley now. would be great to know if that's the correct way to upgrade contract as can't see example within the repo (https://github.com/o1-labs/snarkyjs/blob/926e2a22062aa55fe2d99926372168803bac8255/src/examples/zkapps/dex/upgradability.ts#L434 only this but not really showing the correct path...)
visual iron
You could be right. But if the transaction hasn't been written to a block yet then for V2 it would just have the old state for the counter (i.e. 1), which looks to be the case. Your transaction is trying to set it to 0, but instead the value you are retrieving is 1, which is what it is set to when the transaction is first deployed. Does this make sense?
Is it possible for you to add a wait with max attempts to line 54 (like you have on line 41) just to make sure you give it more time. Alternatively, it could be that the transaction is failing in some way.
tepid scarab
old state was 10, and zkappv1 still returns 10 although the new verification key was set to V2
I've added explicit function to set counter and action hash to 0 and that works, but I'm still able to call zkappV1.counter and get 10 and zkappV2.counter returns 0 😅 maybe local mina is caching the V1 and that's why it returns 10? not sure
currently fighting to try run it on Berkeley
visual iron
Am I right in thinking you have two different Smart Contracts deployed to the same address? But presumably they have different Token Ids.
tepid scarab
ah sorry maybe I haven't clarified it well.
I have a V1 contract that has counter and associated action to do with it.
I want to 'upgrade' the V1 to V2 with the same address but replace logic on how action modify counter. Ideally move state to V2. (which I assumed as the account is the same, just changing verification key)
visual iron
Ah, OK. Thanks for clarifying, Karol. Are you expecting the counter on V1 to be replaced by the counter on V2, when you deploy V2?
tepid scarab
no, I expected when I call counter on V2 it will return old state and I can modify it with new logic
visual iron
That's good. Yes, I was going to say I wouldn't expect that kind of behaviour from V1.
copper canyon
@tepid scarab are you sure the second of those jest test cases waits until the first has finished running?
also, one thing I noticed: just doing
Mina.transaction(sender, () => {
zkappV2.counter.set(Field(0));
})
is probably not enough to update state
I think likely there is no account update included in the tx
to confirm it's always a good idea to print tx.toPretty() if a tx doesn't do what you expect
I think this can be an explicit way to add the zkapp account update and change state, if you don't want to do it in a method (i.e. without proof):
Mina.transaction(sender, () => {
AccountUpdate.attachToTransaction(zkappV2.self);
zkappV2.counter.set(Field(0));
})
@tepid scarab ^^
(if you call a @method this is done automatically)
tepid scarab
I've moved it up to same jest test case, and I checked if the verification key was actually updated on the account. it is changed and.... counter is 3 😮 🤯 ?!
