Reject and do what? Once the contract has been deployed you must execute it no matter how hard it is.
What currently looks promising for wasm are so called “baseline” JITs. These sacrifice optimization of the final machine code but are capable of performing verification and compilation in a single pass. Both SpiderMonkey (Firefox) and V8 (Chrome, nodejs) now have those.
We should have some number for Devcon.
I’m still not wanting to trust third-party Wasm VMs unless we can deal with the source well enough to be confident they aren’t vulnerable to attacks, and that we can rapidly fix attacks that slip past us. But I haven’t inspected the source.
Having lived for years inside an older Java VM I’d be amazed if recent ones weren’t huge attack surfaces, even the “baseline” parts. And I’d despair of fully understanding or safely modifying their source. How different Wasm VMs are I don’t know, but quadratic optimizations are vulnerable, hash tables are vulnerable, caches are vulnerable, and more.
You could arguably have a two stage deploy procedure, where you first deploy it, and then compile it. Compilation would be a pre-compiled smartcontract by itself.
An easier option is to do optimizing compilation to Wasm code, then do simple code generation from the Wasm code. Wasm was designed for this.
@gcolvin nice find. I like the minimal memory footprint & shall be trying out optimisation of the wrc20 example contract’s wasm code.
I am guessing this “optimisation” is to be considered as a post-chiseling process?