search

tomusdrw / rust-web3

Ethereum JSON-RPC multi-transport client. Rust implementation of web3 library. ENS address: rust-web3.eth
MIT License
1.45k stars 466 forks source link

support `no_std` #21

Open rphmeier opened 7 years ago

fubuloubu commented 5 years ago

I would like to take a crack at this over the next few weeks, if possible. I eventually need to use this library in a Substrate runtime to have an Ethereum bridge to my chain.

@rphmeier @tomusdrw What do you think would be a good start to support this?

tomusdrw commented 5 years ago

@fubuloubu If your goal is to compile to WASM, I think that:

$ cargo check --target wasm32-unknown-unknown --no-default-features

would be a good starting point. Then fixing dependencies one-by-one to make sure they compile when targeting wasm (i.e. avoid threads, io, etc).

fubuloubu commented 5 years ago

Oh, great tip! Thanks!

I have a smaller library to upgrade first, so this will get me there eventually.

fubuloubu commented 5 years ago

@tomusdrw would it be okay to upgrade all uses of HashMap to use BTreeMap instead?

Edit: I'm working through the error list of doing this upgrade, down to some 36 errors from 300+, so making good progress!

rphmeier commented 5 years ago

We may also have to make a decision on what functionality we want to feature-gate to std only. For instance, we almost definitely want to leave the transport traits, but the implementations for WebSockets, IPC, and http almost definitely require std.

tomusdrw commented 5 years ago

I just re-read that you want to use it inside substrate runtime. This will cause additional issues and require no_std feature and depending on core/alloc stuff.

Switching to BTreeMap imho should be feature-gated as well, it can have pretty big performance impact.

fubuloubu commented 5 years ago

Cool, well I'll see if I can get it working in a branch and will maybe submit a PR to figure out how to handle gating with no_std. Sound like a good plan?

fubuloubu commented 5 years ago

The other big issue I had is std::error::Error/std::io::Error. Not sure how best to handle this, but it doesn't look trivial to swap out from my limited knowledge.

fubuloubu commented 4 years ago

I've been thinking about this a bit more, and it probably makes more sense if just the Web3-specific types are available as no_std, perhaps as a separate crate.

A great example of this is Bytes, which I am using in the https://github.com/ethpm/ethpm-rs repo to serialize/deserialize ethPM packages. Other types would be very helpful as well.

ioannist commented 2 years ago

Any progress on no_std support?