# Announcing PolkaVM - a new RISC-V based VM for smart contracts (and possibly more!) **URL:** \ **Category:** Tech Talk\ **Tags:** wasm, smart-contracts\ **Created:** [August 30, 2023, 8:09pm UTC](https://forum.polkadot.network/t/announcing-polkavm-a-new-risc-v-based-vm-for-smart-contracts-and-possibly-more/3811 "2023-08-30T20:09:17Z")\ **Posts on this page:** 1\ **Showing post:** 4
**Author:** ![koute](https://dub1.discourse-cdn.com/flex005/user_avatar/forum.polkadot.network/koute/32/1457_2.png) [@koute](https://forum.polkadot.network/u/koute)\ **Post date:** [August 31, 2023, 11:52am UTC](https://forum.polkadot.network/t/announcing-polkavm-a-new-risc-v-based-vm-for-smart-contracts-and-possibly-more/3811/4 "2023-08-31T11:52:03Z")
> [@tomaka](#): > > But it depends on Linux-only capabilities, right? Or does it work on Windows for example? The _sandboxing_ implementation as currently implemented is Linux-only. The zero dependencies claim was more of a “we don’t depend on much external Rust code”, and not a “this is completely OS independent”. We still depend on the OS, mostly for sandboxing. As far as Windows support goes, there are a few options: 1. Run an interpreter. This doesn’t recompile the program into native code and is very simple, so it doesn’t need any extra sandboxing. This already works and is supported _today_. 2. Run the guest program in a `wasmtime`-like sandbox. This will also work on Windows, but it’s nowhere near as secure. This is currently not implemented, but I might add it in the future. 3. Run the guest program under a system-level virtual machine (e.g. Hyper-V on Windows). This would be as secure as what we have under Linux, but will require highly OS-specific code. (And I’m not a Windows expert so I don’t know off the top of my head how feasible that is. I’d like to experiment with it in the future though.) > [@tomaka](#): > > I’m a bit confused by this point, because I thought that the RISC-V interpreter/JIT/whatever would run inside of the Wasm runtime. By definition a recompiler which emits native code cannot fully run inside of a WASM runtime. The VM _could_ run inside of a WASM runtime as an interpreter, but we want to run it _outside_ (because we want to maximize the performance) and we’ll expose this through appropriate host functions that the runtime will be able to call to instantiate the VM. If you’re wondering whether you’d be able to use this inside smoldot - yes. You’d just include it as a dependency, and it’d work out-of-box. If the target for which the VM is compiled is not explicitly supported by the recompiler it’ll just automatically fall back to use the interpreter. (It will be slower of course, but I assume light clients are not going to run heavy computations through it, right?) > [@tomaka](#): > > Has the objective changed so that it would completely replace Wasm for the runtime in the long term? For the runtimes it’s not completely out of the question, but at this point in time - no, there are no plans. Currently we’re doing this strictly for smart contracts, however the VM itself is pretty much a general purpose VM - it’s designed so that it should be able to check all of the boxes which smart contracts need (e.g. it’s already as fast as the fastest singlepass WASM VM), but it’s not constrained by those needs and could, in theory, be used for full fat runtimes. So what’s planned is that we will _experiment_ with running normal runtimes on it, and depending on the results we can have a “should we also switch our runtimes to it?” conversation, but at this point it’s not clear whether it’d be worth it. It’s pointless to switch just for the fun of it, and there _must_ be clear benefits of doing so. > [@dmitry.sinyavin](#): > > I’d say we shouldn’t because we cannot. That microarchitectural behavior may differ between different generations of CPUs, not even mentioning the Intel-AMD difference. Indeed! For a single model of a CPU _maybe_ it could be possible (but _extremely_ hard), but for multiple? It’d be just impossible, since every model will be slightly different. That said, there _are_ certain microarchitectural properties that essentially _all_ modern high performance CPUs share, and will have for the forseeable future. The example I cited in my post with cache associativity is something that, I think, will change (e.g. due do different cache sizes, different N-ary associativities, etc.), so it wasn’t the best example of what we could try to model. However, for example, every modern high performance CPU is superscalar, and this is something that, I think, might be relatively easy to model. Of course the objective here is not to “model exactly what CPU does”, but to “model it a _little_ bit more accurately”. So the simplest idea that we could try here: instead of looking at single instructions look at _pairs_ of instructions, see if they’re independent, and if so assume the CPU can run them in parallel (and essentially every modern CPU _will_ do this, with a few exceptions). So we’d still get 100% deterministic results, but they would match the reality a little bit better. (Of course, how much this would help is still an open question and needs to be benchmarked.) --- _[View the full topic](https://forum.polkadot.network/t/announcing-polkavm-a-new-risc-v-based-vm-for-smart-contracts-and-possibly-more/3811)._