Deterministic contract errors vs non deterministic vm errors

[alpe]

Currently contract devs have a hard time to find out the root cause for contract errors. This pops up on discord and wasmd issues regular.

• Emit any redacted errors as events wasmd#1122
• SmartQuery errors are redacted wasmd#1160

@ethanfrey suggested on internal slack to separate out (deterministic) “contract-originating errors” as a subset of (non-deterministic) “wasmer-originating errors”.
The “contract-originating errors” would be a big step towards better dev UX already.

[ethanfrey]

The only things in the SDK we can trust as fully deterministic are "state writes" (including ordering), the data returned on a message, and the error code (but not codespace !?).

Error can definitely change between any two systems or any patch version and thus can never be exposed to contracts, which might write them to state.

However, with wasm, we also guarantee the exact same code running on each machine and the result returned by any import should be considered deterministic (writes, events, errors, gas usage, submessages, etc). In only this case could we expose the event to other state machine code.

We need to be careful to distinguish wasmer/vm-errors (which are raised on panic, out of gas, etc) and a string returned directly from a wasm contract. Only in the second case can we expose this to other contracts. This likely needs some updates to wasmvm to allow such distinction to be made

[webmaster128]

Requires CosmWasm/wasmvm#398

[0xLaurenzo]

After looking through cosmwasm-vm and wasmvm, I think we might be able to return any error type of type ContractResult.Error to a calling contract in a submsg. I'm not sure what the best way is specifically to catch ContractResult Errors in, but probably it's best to catch these in redactError() similar to

if wasmvmtypes.ToSystemError(err) != nil {
		return err
	}

an example of an call to a contract in wasmvm is the execute api call

[0xLaurenzo]

After talking about this issue in discord, I heard there were some backwards compatibility issues. AFAIK, these changes would only introduce backwards incompatibility in the sense that they are state breaking. Returning submsg errors should not affect direct calls to smart contracts or successful contract behavior. Given that and the huge amount of DX increase this gives us, I think it's still worth considering or looking for a way to include this sooner

[nicolaslara]

The only things in the SDK we can trust as fully deterministic are "state writes" (including ordering), the data returned on a message, and the error code (but not codespace !?).

There's a discussion about including codespace in cometbft/cometbft#844

[webmaster128]

There is nothing to be done in this repo. Please follow CosmWasm/wasmvm#398 for progress on the matter discussed here. Thanks everyone for your participation – appreciate it.