SubstrateVM?
Interesting, so this VM isn’t expected to be of much interest/use to those participants? From the thread subject:
… a new RISC-V based VM for smart contracts (and possibly more!)
Okay, but the Substrate universe need not just be Polkadot. Not my itch, but I can imagine one day someone wondering how close to a Solana type of block tick Substrate can get.
You can never have too much headroom.
@koute Can you approve “PVM” instead of “PolkaVM” because @gavofyork is doing so already here:
Or, can you christen the precise difference between the terms “PVM” and “PolkaVM” and what “P” in “PVM” refers to (“Polka” vs “Polkadot” vs “Play”)? Having clarified by you will help the marketeers and community get some nice clear terminology to run with for the rest of 2024! Thank you!
Nothing Polkadot has built so far as been proprietary so i don’t see how PolkaVM would bring negative connotations.
The name is great IMO and if necessary we can always subtitle it with “free and open source” in marketting campaigns.
To be fair this is almost always the case. There lies a tradeoff. If you want a correct name you will need a new term like “PolkaVM” or “Pallet”. But if you want a recognizeable term like “RISC-V VM” you will need to accept to be wrong. This is because of all the meaning people already connect with this term.
The point @natalie is trying to make if I get it correctly is that it is better to be wrong but have a recognizeable name from a marketing perspective. I understand that engineers rather be correct
That doesn’t mean I am agreeing that RISC-V VM would be a good name. Nor do I think that PolkaVM is a bad name.
Just wanting to point that out because that argument was used to make, in my opinion, bad naming decision in the past.
But from a marketing perspective it should be enough to talk about RISC-V based VM? I mean PolkaVM is the Parity provided implementation, but that doesn’t mean that every Polkadot node implementation will need to use this. They can use whatever implementation of the same standard.
Yes. I think when talking about PolkaVM the implementation we should mention that it is a “RISC-V based VM”. But it is more a description than a name.
And if you think about it “RISC-V based VM” is basically a placeholder for the standard we have yet to define.
To me this seems sensible:
- Keep PolkaVM as the name for Parity’s implementation of a “RISC-V based VM”.
- Come up with a name for the “RISC-V based VM” standard. Ideally, something marketable.
This will connect our implementation to Polkadot. But keep the standard neutral in naming. Basically what @koute suggested.
The only downside of the name PolkaVM is that it will probably not be connected to the name of the standard. wasmtime, wasmer and wasmi are all connected in that way. Not sure how important that is though.
That sounds reasonable
RVM/R5VM? Does it need to be more complicated than that?
Yes that’s good and thanks for clarifying, makes sense to have 2 levels of naming, one neutral and descriptive for the standard and ideally used elsewhere, and one branded for Parity’s implementation.
Yes, I like! (from now on, as we’ve agreed on the strategy, it’s more a preference question than theory, if we don’t do surveys which I don’t think are necessary). So, personally, I like the one with the 5 more
(APPENDIX) One comment about this:
There is more to branding & naming strategies than this I’m afraid In this particular case, the examples don’t work because you are talking about products with different touch points for the user. You are talking about the names / brands that customers directly interact with. Imagine a car company. BMW, Daimler, … That’s the customer-facing brand. Underneath, you have a lot of well-known components (body, engine, wheels, …), with sub-components (steel, cylinders, valves, screws, …).
Some of them describe your unique attributes, but even then, you’d describe them ideally with well-known terms (electric engine, 7-gear shifter, …). On this level, you can find a few terms that are branded, but mainly because they don’t have a category yet (e.g. the “BMW IconicSounds Electric” - yes I googled, which replicates driving sounds for electric cars).
You see, the further we go down the “stack”, and further away from the user, the less we need specific “brands” and the easier we make it for people to interpret things. Imagine you’d have a bullet list of features and you recognise none of them.
So, the Chrome and Linux examples won’t hold true here as they are the user-facing brand (like Polkadot) and we can’t follow from that to giving everything their own brand identity.
Wanted to clarify this - I’d be careful going forward with getting to simple conclusions, there’s usually a bit more thinking behind marketing approaches.
So if the binary representations and tool chaining between targets are OS and hardware independent, they could just be running physically on an actual RISC-V processor without much intermediaries ?
I assume by “physical” you mean executing without a sandbox: Even on RISC-V Linux we would need some form of sandboxing. I see no reason why we would chose a different sandboxing setup than we are using on x64 Linux. It also can’t be run bare metal (without an OS) as it is always embedded into a host application as that’s PolkaVM’s purpose.
However, since we are essentially JITing RISC-V to RISC-V (we have some custom instructions that need to be translated) the produced code probably suffers less of an execution slow down relative to x64. So given we would support this use case an RISC-V Linux based validator would probably have some performance advantages all other things being equal.
Afaik, real RISC-V hardware has far more registers, so you’ll hit cache more than regular RISC-V hardqware expects, but less than x86 code expects. It’ll be considerably slower than native RISC-V code.
If real RISC-V hardware becomes commonplace in future, then one could explore variations, like annotations for push & pop instructions that shift register allocations instead.
Anyways…
There are two flavors of polkavm gas discussed, strict where the aborted state remains usable, and non-strict where the aborted state becomes invalid, so likely we’ll always use one or the other of those. If otoh one used polkavm without any gas metering, then radically different performance characteristics would still impose costs.
The reduced register set ISA is intended for real hardware. That said, you are right your validator will probably run a CPU with the full register set.
Are you sure about that? Our experiments showed that additional registers have diminishing returns. But at this point it is mostly speculation. So maybe you should not write as if this is a fact.
How is this related to the question?
Honestly, this very highly depends on the microarchitecture of the CPU you’re running on, so you can’t really confidently say one way or the other. Modern CPUs have hundreds of registers regardless of how many are exposed through the instruction set.
Nevertheless, with the currently available hardware a native RISC-V CPU is always going to be slower regardless of what we do, simply because all currently available RISC-V hardware is extremely slow, so it’s kind of a moot point.
This might change in the future, but by then we’ll probably have the new 32-register AMD64 extension widely available (we’ll probably have to wait at least a decade for this, if not longer) and then will can consider switching to the 32-register RISC-V if it’s worth it.

Nevertheless, with the currently available hardware a native RISC-V CPU is always going to be slower regardless of what we do, simply because all currently available RISC-V hardware is extremely slow, so it’s kind of a moot point.
Yes exactly. This is why I said all other things being equal. Those are not equal as of right now as you pointed out.