Get the light client to compile for wasm

[tomaka]

cc @rphmeier

In order to be able to run the light client inside of a browser extension.

Problematic libraries include mio (doesn't support emscripten), ring (uses raw assembly), rocksdb and openssl (both will be hard to compile).

[kirushik]

openssl will likely be replaced with rustls as a part of #7829, so it's eventually will be the ring issue again.

[tomaka]

A good first step for this issue is either #7954 or #7955.

[rphmeier]

I would break up the tasks for this like so:

• Take ethcore-io stuff out of ethcore to cut out the mio dependency.
• Break out any explicit dependency on ethcore-network from ethcore-light, instead doing everything through traits
• Break out any explicit dependency on rocksdb from ethcore-light (this may already not exist as everything is done through the KeyValueDb trait).
• Separate the light client sync algorithm from the ethsync module to get rid of ethcore-network dependency.
• Compile ethcore-light, parity-rpc, and new ethcore-light-sync crate for WASM.
• Write a Rust wrapper which expects extern functions that can provide network and DB context somehow and also exports a function for making RPC calls.
• Write JS code that uses libp2p and local storage to fulfill the requirements of the Rust wrapper and can use its RPC function to answer its queries

Ring will definitely pose an issue because signing libraries are depended on by parity-rpc transitively through the ethkey dependency. We might need to further generalize or split up this crate to avoid that and provide the crypto stuff on the JS side or through some other library :\

[tomaka]

Should the network code be hard-coded to libp2p/devp2p (eg. pass an instance of libp2p::Transport), or should it be more generic?

I'd go for the first option, because Parity may depend on some very specific networking behaviours. If we go for the second option, not only would the API be very complex, but every single corner case would need to be documented.

[rphmeier]

Keeping it generic seems the best way to make it testable. Right now the light client network code is fairly network-independent and exposes a few hooks that can be called by devp2p or libp2p or an in-memory test network.

In general, how are you supposed to unit test libp2p-based code?

[tomaka]

In general, how are you supposed to unit test libp2p-based code?

You can fairly easily create an implementation of the Transport trait that reads/write to/from memory, or that calls a custom handler.

[tomaka]

Take ethcore-io stuff out of ethcore to cut out the mio dependency.

This is really difficult, so instead I suggest adding an optional mio feature to ethcore-io.
Only network-devp2p would require that mio feature.

EDIT: Although I'm not sure ; removing ethcore-io would definitely be a much cleaner solution.

[tomaka]

Notes for myself for crypto libraries alternatives:

• https://github.com/dalek-cryptography
• https://github.com/RustCrypto
• https://gitlab.com/sequoia-pgp

[adria0]

Closing issue due to its stale state.