Newer rust nightly toolchains emit sign extenesion opcodes by default and we currently don’t support these.
The thing here is to try to backport this PR wasmi-labs/wasmi#360 onto our fork https://github.com/casper-network/casper-wasmi
Some context: we’ve forked wasmi 0.13.2 (used to be considered ‘rock solid’ release and used by polkadot for a very long time) which is last release before they started to break APIs. There’s a lot of effort involved to use upstream wasmi due to many API changes, so we have this fork on life support. There were some security fixes as well. But it lacks some features that are getting more common in the compilers (i.e. sign ext, bulk memory). We’ve figured with Karan it may be worthwile to give it a shot and backport said PR ontop of our fork and see what happens. If we succeed it’s great, we don’t need to worry about compilers using “fancy” wasm extensions by default, otherwise if it takes more than day or two we may as well wait for new engine with different VM
Newer rust nightly toolchains emit sign extenesion opcodes by default and we currently don’t support these.
The thing here is to try to backport this PR wasmi-labs/wasmi#360 onto our fork https://github.com/casper-network/casper-wasmi
Some context: we’ve forked wasmi 0.13.2 (used to be considered ‘rock solid’ release and used by polkadot for a very long time) which is last release before they started to break APIs. There’s a lot of effort involved to use upstream wasmi due to many API changes, so we have this fork on life support. There were some security fixes as well. But it lacks some features that are getting more common in the compilers (i.e. sign ext, bulk memory). We’ve figured with Karan it may be worthwile to give it a shot and backport said PR ontop of our fork and see what happens. If we succeed it’s great, we don’t need to worry about compilers using “fancy” wasm extensions by default, otherwise if it takes more than day or two we may as well wait for new engine with different VM