wasm store failure: reference-types not enabled: zero byte expected (at offset 0x11da)

[robert-zaremba]

When executing wasm store ... I'm receiving this error:

raw_log: 'failed to execute message; message index: 0: Error calling the VM: Error
  during static Wasm validation: Wasm bytecode could not be deserialized. Deserialization
  error: "reference-types not enabled: zero byte expected (at offset 0x11da)": create
  wasm contract failed'

Compilation works fine.

My deps in Cargo.toml:

cosmwasm-std = { version = "2.1.0", features = ["cosmwasm_2_1", "stargate"], deafult-features = false }

• rustc version: rustc 1.82.0 (f6e511eec 2024-10-15)
• platform: linux
• target wasm

[robert-zaremba]

Had chat with @webmaster128 . Apparently it's related to the new rustc release - they included new experimental features to the wasm , that are not supported by wasmd (wasmer). So the solution is to downgrade to v1.81:

rustup default 1.81
rustup target add wasm32-unknown-unknown

Let's leave this issue open until wasmd supports latest rust.

[webmaster128]

Latest cosmwasm/optimizer (0.16.1) also works because it contains Rust 1.81.0

[webmaster128]

Reference types are enabled on chains running CosmWasm 2.2 (wasmvm 2.2.x) which is the next version to be released

[chipshort]

I'm closing here, since this is solved on main and can be worked around as described above.

[jhernandezb]

We recently upgraded our testnet network from 1.5 to 2.1.4 and statesync is now giving this issue

"extension wasm restore: processing snapshot item: Error calling the VM: Error during static Wasm validation: Wasm 
bytecode could not be deserialized. Deserialization error: \"reference-types not enabled: zero byte expected (at offset 
0x864c)\": create wasm contract failed" module=server

[chipshort]

@jhernandezb It's very curious that this is happening in state-sync. We allowed the reference types intermittently in some 2.2 release candidate versions, but had to ultimately roll back in #2311 because wasmer does not fully support reference types yet, so we have to wait for them.
In other words: reference-types should be disallowed both in 1.5 and 2.2.

[jhernandezb]

@chipshort is it possible that 1.5 allowed it to upload with recent versions of the compiler?

I checked parsed_wasm.rs and it was using the default (enabled) https://github.com/CosmWasm/cosmwasm/blob/release/1.5/packages/vm/src/parsed_wasm.rs#L33

but this disabled in gatekeeper https://github.com/CosmWasm/cosmwasm/blob/release/1.5/packages/vm/src/wasm_backend/gatekeeper.rs#L22C5-L22C34

Not really sure whats the different in both settings tho.

[jhernandezb]

added a test to gatekeeper

    #[test]
    fn reference_types_not_supported() {
        let wasm = wat::parse_str(
            r#"
            (type $x1 (func (param funcref)))
            (import "env" "abort" (func $f (type $x1)))
            "#,
        )
        .unwrap();

        let deterministic = Arc::new(Gatekeeper::default());
        let mut compiler = make_compiler_config();
        compiler.push_middleware(deterministic);
        let store = Store::new(compiler);
        let result = Module::new(&store, wasm);
        assert!(result.unwrap_err().to_string().contains("reference-types"));
    }

This will panic in 2.2 (expected) but this works in 1.5

[chipshort]

This will panic in 2.2 (expected) but this works in 1.5

Are you sure? For me, this panics both on main, as well as release/1.5
Note that you need to use Singlepass::default instead of make_compiler_config in 1.5, since that's the compiler being used in the actual production code (looks like some of the tests were still using cranelift back then, but the official libwasmvm build uses singlepass)

[chipshort]

Do you know which wasm file causes this problem? I'd like to do some tests with that if possible.

[jhernandezb]

This will panic in 2.2 (expected) but this works in 1.5

Are you sure? For me, this panics both on main, as well as release/1.5 Note that you need to use Singlepass::default instead of make_compiler_config in 1.5, since that's the compiler being used in the actual production code (looks like some of the tests were still using cranelift back then, but the official libwasmvm build uses singlepass)

You are right, let me try to get the wasm that fails during statesync