error: [ 'The wrong nonce' ] for each interaction when using VM2 in Warp Contracts

[ppedziwiatr]

Hey,

my name is Piotr, I work on the Warp Contracts project.
We've recently launched a new execution node - details are available here https://github.com/warp-contracts/warp-dre-node#warp-dre

Unfortunately - while analysing the logs from the DRE node - I've noticed that WeaveDB contracts (e.g. https://sonar.warp.cc/#/app/contract/QAjM3_MklqXSXr-7z_J7t0UqEAyjBpqQDF9NDzf_JPU#code) fail to execute.

The original issue was caused by the bug in the VM2 - patriksimek/vm2#485
It has been now fixed and the contract loads properly under VM2 - but each interaction ends with

error: [ 'The wrong nonce' ]

(which differs from when contract is not executed within the VM2).

I wonder if you're willing to help us to solve this issue (it's kinda difficult to understand what your contract is doing - it has thousands lines of code of some external libraries)?

[ppedziwiatr]

As a side note: https://docs.weavedb.dev/docs/exm/comparison
Reading Outside Data: only Arweave (unsafe) is not true - it is possible to load any kind of outside data from any endpoint in Warp - but obviously that's non deterministic and unsafe operation (just like reading data from Arweave).

Not sure how deterministicFetch in EXM works (the source code of the EXM backend is private), the only thing I can imagine is that EXM simply stores all results of the original deterministFetch call - and then serves them when the same call is being made - but then you need to trust, that the stored result was not manipulated in any way.

[ocrybit]

Hi, thank you for letting me know. Yes, I'm aware that our contracts have problems with the latest warp SDK and VM2.

The old WeaveDB contracts only work with warp-contracts@1.2.26 without VM2.

I'm working on re-implementing a major part of our codebase to make it compatible with the latest warp SDK and VM2, but struggling with a couple of issues.

The first issue was the change to unset Function when evaluating the contract code.(the change @1.2.27)
warp-contracts/warp@deff303#diff-b2e9f18ceda829962e5d82052d3e1c9ed69a81da6c1faca4eff0883bdace89cdR35

I removed the dependency to Function so this one has been solved, and my code is compatible with warp-contracts@1.2.27 now.

But then I'm facing another issue to keep it compatible with VM2. You added this line @1.2.28 and it's now breaking the code which was once compatible with VM2.
warp-contracts/warp@c48661a#diff-112e5f7250bd1f0f63a10578cb6a728e1123b61da6170dbbab77ebc4c64b38f0R187

I think patriksimek/vm2#491 is caused by the change above because my contracts are getting the same errors after @1.2.28. (They were working @1.2.27)

I also see this conversation, which I think is related to the Arweave signature verification.
patriksimek/vm2#484

So my situation now is, either you revert this change and find another solution without the workaround to VM2, or I need to replace the core crypto libraries to work around your workaround...

[ocrybit]

error: [ 'The wrong nonce' ]

The reason you get this error is because the nonces are incremental for each user address like blockchain transactions. So if there is a discrepancy between execution environments and one of the earlier transactions fails, all transactions thereafter fail with the wrong nonces.

[ocrybit]

the only thing I can imagine is that EXM simply stores all results of the original deterministFetch call

I think they save results from deterministicFetch in transactions, so the original results are immutably stored on Arweave without manipulations. I'm not sure how read queries with time variables work, but I don't think they distinguish read and write calls like Warp does (I need to experiment with this to be sure).

it is possible to load any kind of outside data from any endpoint in Warp

OK, I wasn't aware of this. Maybe by using fetch? I thought external data access is only possible with getData, but ok I will experiment some more and update the docs accordingly.

[ppedziwiatr]

But then I'm facing another issue to keep it compatible with VM2. You added this line @1.2.28 and it's now breaking the code which was once compatible with VM2.
warp-contracts/warp@c48661a#diff-112e5f7250bd1f0f63a10578cb6a728e1123b61da6170dbbab77ebc4c64b38f0R187

I'm happy to revert this change, but are you sure that your contracts work (i.e. evaluate properly) without this fix? The only reason it was added was the error shown in patriksimek/vm2#484 (comment) (which was coming from one of the weavedb contracts).

Btw. the other option is a change suggested by VM2 developers - patriksimek/vm2#484 (comment)

[ocrybit]

Hi, so I've rewritten a big part of our contracts and figured out a way to make it all work with vm2. Rather than reverting the change, I would like to ask you to expose Uint32Array too, as suggested here patriksimek/vm2#484 (comment).
Please check out my pull request warp-contracts/warp#301.

[ocrybit]

This issue has been solved for the new WeaveDB contracts(v0.8) with warp-contracts/warp#301.
But for the old contracts(v0.7 and lower), you need to use warp-contracts@1.2.26 with vm2 turned off.