Implement our runtime with github.com/tetratelabs/wazero

[qdm12]

Task summary

1. Implement the same functionality as wasmer with wazero in lib/runtime
2. Remove the lib/runtime/wasmer implementation

This is likely at least one week of work since all the code lib/runtime has to be modified, and tests adapted to work with wazero without cgo.

Outcomes

1. Faster debugging: no more CGO, so no more weird unknown pc pointer stack traces
2. Less dependencies: no need for glibc and libwasmer.so
3. Faster Go compilation
4. Lighter Docker images since we can now have alpine based or scratch based Docker images

Other information and links

• Performance wise, I do not think it would matter if it's slower. Our performance should be mostly hit by the scale codec code.

[danforbes]

Should this replace #1268?

[qdm12]

What do you think @timwu20 ?

Personally I would rather have a single Go runtime to throw out CGO, but we could also have different binaries/different build tags to have a fully Go version and a CGO one. 🤔

[danforbes]

What is the benefit of offering both options? When would someone ever want to select the CGO option?

[qdm12]

I'd say it's unclear for now, but maybe one runtime uses less or more resources. I'd say we can take the decision to 'prune' wasmer once wazero is implemented if it's superior/close enough in terms of performance.

[codefromthecrypt]

ooops put our notes on the wrong issue https://github.com/ChainSafe/gossamer/pull/2749#issuecomment-1231368454

ps we owe a huge page on the issues on CGO, though not all are obvious at first. Some will want to avoid it for docker alone, not just smaller but a lot simpler vs tracking shared libs etc https://gist.github.com/codefromthecrypt/edb33284354d592dc6056b9b7263872f

[qdm12]

Thanks @codefromthecrypt We are well aware of CGO problems, and wazero looks like the best solution for Go (CGO or not).

Not only wasmer/cgo has production disadvantages, but it's also a pain in terms of development (notably unreadable panic messages instead of native Go panics when a Go nil pointer not even touching CGO is dereferenced, devs are forced to use glibc OSes with C libraries).

Anyway hoping to do this migration soon! #2749 got merged so one step closer! 👍