Hi everyone,
I'm experimenting with a Wasmtime embedding that virtualizes selected WASI Preview 2 interfaces (clocks, random, selected filesystem ops).
Runtime sequence in the prototype:
So execution-time resolution and real-world materialization are intentionally split.
Replay mode resolves effects strictly from the recorded log.
This is an embedding strategy only; it does not propose changes to WASI or the Component Model.
I'm curious:
Is there existing ecosystem work overlapping with this log-and-defer approach?
Are there Wasmtime constraints (resource tables, async model, canonical ABI lowering/lifting) that make this problematic, especially for filesystem handles?
Would a minimal artifact (embedding + replay demo) be useful for discussion here or is there a better forum?
i don't know about defer but this seems similar to durable computation systems where one records effects in a log tape to allow replay. Look at https://obeli.sk/ for an example and I'm currently using a rough port of restate.dev 's design in a project over wasm.
Thanks for the suggestions! I was familiar with Restate, not with obelisk. Although they're higher level/more domain oriented than what I have in mind, obelisk definitely helps me confirm my direction is at least sane. I'd be very interested in anything you've learned from the Restate port?
If you aren't already aware, I think you'd be interested in how wasi-virt virtualizes wasi interfaces: http://github.com/bytecodealliance/wasi-virt
@Bailey Hayes Thanks for the suggestion! I looked at the repo and it's very relevant. After seeing it, I tried to seam carve replay on top of it. But targeting the WASI P2 seems a bit harder than expected, so I'm currently focusing an a more narrow path: a runtime mediation + deterministic replay engine over a custom ABI (clocks, stdio/input, fs, net, entropy). Moving from build time virt to runtime also allows for late-binding policy choices.
Last updated: Mar 23 2026 at 16:19 UTC