acoustic bloom
I'm looking to learn more about folks who are using the Soroban Env Host to build to Wasm to run in the browser.
Do folks know who is doing that?
There's a real possibility that dependencies might need to be included into the host, where those dependencies might break the hosts ability to build to Wasm.
@dawn field trying to remember do you run the host in the browser? Or run it server side?
dawn field
Howdy! @acoustic bloom just saw your message. I'm running it in the browser, client-side.
I would really be interesting in learning more about this.
acoustic bloom
@coarse galleon iirc my questions here were prompted by a discussion with you about the possibility of including new dependencies (another wasm runtime?) that’d mean it couldn’t build to wasm. Could you share more clarity on that?
coarse galleon
we're exploring a move to a JIT (winch) rather than the interpreter (wasmi) we currently use. the various barriers that prevented the use of a JIT before are mostly overcome now. so we're considering it.
if we do that, the JIT generates .. x86-64 or arm machine code
which, you know, is something you aren't allowed to just flip the execute bit on the containing page and jump into on a browser
so the host, compiled to wasm, would not be able to run any of the code the JIT emits
one option would be to continue to also ship an interpreter. wasmtime (which is the overall project we're targeting) is working on an interpreter mode. so we could interpret guests when the host is compiled-to-wasm, and otherwise JIT guests when the host is compiled-to-native.
but that interpreter (called pulley) is not really done yet. and it'd be more code to include. and if we included it, it would almost certainly have different gas metering than winch (the JIT), so you'd lose some simulation fidelity
(we could regain simulation fidelity by moving to a code-rewriting form of gas, but we'd kinda prefer not to, that's annoying for other reasons)
we can also continue to ship wasmi as the interpreter until pulley is done
or we could have no interpreter, JIT only, and break the host-compiled-to-wasm mode
dim holly
@coarse galleon I assume we'd be caching all the compiled modules if we switch from interpreter to compiler? is this connected to @vapid shadow 's proposal to keep all of soroban state in memory?
dawn field
damn, that would totally break Okashi
@coarse galleon what are the benefits of JIT over an interpreter?
The fact that Soroban compiles executables to WebAssembly unlocks the WASM universe of hosts (web browsers, docker, etc.) and tooling. For me, that was the selling point of Soroban.
dawn field
I do want to clarify one thing about the architecture I'm using.
Okashi loads Soroban executables using the browser WebAssembly module. The host environment itself is implemented in JavaScript, meaning I never interface with the Rust implementation of the Soroban host.
What matters to Okashi is that the Soroban contract executables remain WASM.
acoustic bloom
I do want to clarify one thing about the architecture I'm using.
Okashi loads S...
Okashi loads Soroban executables using the browser WebAssembly module. The host environment itself is implemented in JavaScript
I don't think anything about the JIT will change your flow then.
The contracts will still be .wasm files, nothing is changing about them as an input.
The host functions available to the wasm module aren't changing either.
The thing that is changing is the soroban-env-host crate will compile the wasm modules then later execute them, instead of interpreting them during execution. But that is hopefully an implementation detail in the host.
Today the soroban-env-host can be built to wasm and executed in a browser, which I thought you might have been using. I didn't know you have built your own set of host functions, that's awesome!