Reth to web assembly

[mteam88]

Describe the feature

I would love to be able to compile reth to web assembly. I think that could enable some interesting future development courses.

Additional context

Does anyone else here know much about web assembly and about the feasibility of such an undertaking?
This is a very open-ended issue, feel free to ask questions.

[mattsse]

what parts do you want to use in wasm?

[mteam88]

@mattsse Many things are possible, but an execution layer in wasm would be awesome. It may be a bit too heavy to run through a browser, but as wasm can function almost as an OSI (Docker) container, it would create a portable execution layer.
That was my initial thought, but I realize now there are many different applications if we port the whole thing.

• Portable, low startup time eth nodes (imagine a serverless eth node)
• Permissioned eth nodes
• Cheaper cloud nodes
• Significantly faster-than-js client side eth interaction (see https://github.com/michielpost/MetaMask.Blazor)
• Direct access to eth network from many environments (as opposed to using a cloud node provider like Infura)

I'm sure there are more that I am missing...

[onbjerg]

revm (the EVM impl we use) supports WASM. I don't think making all of reth support WASM makes a lot of sense at this stage since the requirements for running a node in the first place are pretty immense (100s of GB of disk space, good chunk of RAM). Maybe once state expiry/history expiry etc is a thing it would make more sense if the resources required to sync are diminished.

It might make sense to support WASM for some of the individual crates like P2P(?). In that case we should track this individually for each crate with a reasoning

[mteam88]

revm supports wasm? Awesome.
I think I disagree with you that the 100GBs of space and high ram requirements make wasm out of the question.
wasm currently has a low (4gb) max requirement on linear memory but that is expected to change.
The disk space can be stored outside of the wasm module with reth in it in some sort of db wasm module.
There are certainly challenges.

It might make sense for P2P and other crates. More discussion required.

[onbjerg]

It is not currently possible to do this without heavy changes to how reth is structured right now since our database required mmap files which is not a concept in wasm at all. I'm not sure what the particular gain is of supporting wasm?

Portable, low startup time eth nodes (imagine a serverless eth node)

I'm not entirely sure if I understand this, but if you mean serverless as in e.g. AWS lambdas, it doesn't really make sense since you need to be "always online" in order to be caught up with the latest block

Permissioned eth nodes

Could gating RPC behind e.g. an auth service not be "good enough"?

Significantly faster-than-js client side eth interaction

I'd just use revm here, revm also has a built-in ethers-rs provider that fetches state required to execute a block or tx on the fly. We use this in Foundry

Direct access to eth network from many environments

I think this is the one we can discuss the most, but running an Eth node in the browser does not make sense to me since it again requires 100s of GB of storage, a lot of memory, and threads. If running in an extension, I could imagine a pretty abysmal slowdown of the browser - if running in a tab, it won't sync if the tab is suspended

Maybe I am just lacking imagination here, but in any case I think this is far out in the future (given above constraints for the DB cannot hold in WASM) and requires a lot more careful thought. Because of that I will convert this to a discussion instead (we're trying to keep the issue tracker actionable)

[mteam88]

I think the serverless node requires more fundamental changes then we would be willing to make.
Permissioned eth nodes: eth nodes themselves limited to certain X (ports, memory, disk space, etc...), not permissioned rpc
Remember, wasm is not just in the browser. Wasm can be run on any OS and reminds me of a docker container.
Let's keep talking.

[onbjerg]

I would just defer to docker or other container runtimes for permissioned nodes since all container runtimes allow you to limit volumes, networking and other resources

[mteam88]

Fair point.

[mattsse]

one of the limiting factors is: there's no filesystem in wasm.
The entire node depends on disk and net IO, so this seems out of scope.

however if you're interested in running evm in wasm, this is already possible

[mteam88]

you have a point