Bump wasmer

[Ekleog-NEAR]

Leaving as draft until wasmer is merged.

Still missing:

• make a protocol change for the new version
• re-enabling tests for VMs other than wasmer2 (this will require figuring out how to use the new finite-wasm instrumentation with other engines)
• completely remove our dependency on pwasm-utils
• check whether this fixes FunctionCallError: expose information about function call execution only (that it is actionable to the end user invoking the contract) #8502

[nagisa]

how to use the new finite-wasm instrumentation with other engines

I think one important step we should take is first release wasmer with all the improvements excluding finite-wasm work, and then as a separate step introduce finite-wasm.

The reason for that is I believe we don't have any breaking changes to wasmer so far, and finite-wasm will require a protocol version bump so we will need to duplicate the dependency and make up another VM type. I think that also opens the way refactoring how our preparation code works – this could be refactored to move to the VM-specific initialization, which is what is happening with the finite-wasm integration in wasmer in the first place.

[nagisa]

Also, am I misremembering, that we were thinking of merging wasmer into nearcore to help with the integration of finite-wasm?

[Ekleog-NEAR]

Also, am I misremembering, that we were thinking of merging wasmer into nearcore to help with the integration of finite-wasm?

My recollection is, we said we should 1. make a new wasmer release, 2. hoist the code into nearcore, and 3. drop our current wasmer codebase. That said, "just" moving wasmer into nearcore altogether would also make sense to me, but we should probably choose between hoisting finite-wasm into wasmer or releasing it as a separate crate first

I think one important step we should take is first release wasmer with all the improvements excluding finite-wasm work, and then as a separate step introduce finite-wasm.

Hmm… I’m not entirely sure about this? I see two possibilities if we do it this way:

• Either we land both changes in a single release, and then there’s no benefit in splitting this PR
• Or we land both changes in two separate releases, and then we take the risk that there actually could have been a protocol change before. For instance, the codegen now requires BMI1; that’s not a protocol change but if the new codegen is different then it could be one. That said, TBH I don’t think there’s much risk in this situation, but I don’t see much benefit in splitting the PR there anyway either

I think that also opens the way refactoring how our preparation code works – this could be refactored to move to the VM-specific initialization, which is what is happening with the finite-wasm integration in wasmer in the first place.

Yup, I definitely need to do that as part of making a protocol change anyway, but I don’t think that’s directly related to whether we upgrade wasmer before or after? Unless you mean we should both upgrade wasmer plus introduce wasmer3, but then I don’t see much point in improving wasmer if it’s going to live for at most one release.