feature: support WasmEdge

[jetjinser]

Is your feature request related to a problem? Please describe.
I want to use ethers-rs on WasmEdge runtime.

Describe the solution you'd like
Supports the features to compile to wasm that can run on WasmEdge.

In order to achieve this, some parts that may need to be changed:

• reqwest => http_req_wasi
• replace wasm-bindgen

not sure.

Describe alternatives you've considered
For now, I use ethers-xxx (ethers-core, ethers-signers), no provider.

[mattsse]

what's the blocker here exactly? because everything compiles to wasm, see wasm example.

[jetjinser]

thank you for your reply

The problem is that wasm-bindgen imports some host functions that wasmedge doesn't.
The wasm example is run in the browser, Maybe it's the difference caused by different hosts, I know very little.
So to summarize, I'm trying to execute a wasm file that depends on ethers-rs with wasmedge, and the error shows unknown import, and this is what happened to me.

[ufoscout]

@mattsse we are facing exactly the same issue.
The problem is that by WASM you mean WASM-inside-a-browser which is not the same thing. In fact, in many places in the code, it is supposed that a JS runtime is available (e.g. #2076). This makes this library not usable in other WASM runtimes.

[slumber]

For anyone still interested here're what's missing to make ethers-providers work in custom wasm runtime:

1. ethers-rs/ethers-providers/Cargo.toml

   Line 69 in f9086e7

   getrandom = { version = "0.2", features = ["js"] }

As per getrandom docs it's not advised to enable js feature in libraries. Currently it's OK because wasm32-* target assumes javascript environment. But in general it's not mandatory for wasm32-wasi, for instance, or if one uses custom feature instead of js and defines external host-based random functionality.

Can be dropped

ws_stream_wasm = "0.7"
wasm-bindgen = "0.2"
wasm-bindgen-futures = "0.4"

These 3 are only necessary if you use ethers websocket implementation or built-in http (which depends on reqwest, which in turn does exactly the same thing). All of its usage can be gated by http and ws features. In general, IMO unconditionally importing *-bindgen and assuming web browser is a bad practice.

Can be gated under features to only be used explicitly

(but note that this means that a user needs to implement custom JsonRpcClient)
3.

web-sys = { version = "0.3", features = ["console"] }
wasm-timer = "0.2"
# this is currently necessary for `wasm-timer::Delay` to work
parking_lot = { version = "0.11", features = ["wasm-bindgen"] }

These dependencies are needed to enable sleeping when polling transaction or waiting on filters:

ethers-rs/ethers-providers/src/utils.rs

Lines 34 to 40 in f9086e7

	// https://github.com/tomusdrw/rust-web3/blob/befcb2fb8f3ca0a43e3081f68886fa327e64c8e6/src/api/eth_filter.rs#L20
	/// Create a stream that emits items at a fixed interval. Used for rate control
	pub fn interval(
	duration: std::time::Duration,
	) -> impl futures_core::stream::Stream<Item = ()> + Send + Unpin {
	stream::unfold((), move |_| Delay::new(duration).map(|_| Some(((), ())))).map(drop)
	}

This can only be dropped for wasi target, wasm32-unknown-unknown doesn't know how to sleep. Options are

• Make it even more customisable and allow defining external sleep (overkill?)
• Disable all polling for wasm target (what's left from ethers then is just types)

No good solution here

I'd conclude that disabling the above defeats the whole purpose of async code and requires too much hustle for a mere typing. My proposal would be to close the issue.