RISC-V is All You Need

[sorpaas]

Polkadot JAM is built on the PVM ISA and it uses an entirely custom instruction set. Last week we announced PVM2, a re-imagination of the PVM ISA towards standard RISC-V.

Our exploration work showed the following: A custom instruction set like PVM is not necessary. We can get competitive performance with almost standard RISC-V. An in-house comparison between our older JAVM (legacy PVM ISA) implementation and the new JAVM (PVM2 ISA) implementation showed identical performance, and both of them are 2x faster than PolkaVM.

Previously we still had to define PVM2 with 4 hard divergences compared with RV64E (hence almost standard). Today we’re announcing another milestone for PVM2 – it’s not almost standard RISC-V anymore, but fully standard compliant RISC-V!

Specification, Xjar + EEI

For the full spec, you can read it here. Two things may be of particular interest to you:

• We define the memory map as a 2³²-fold alias of one 4 GiB main-memory region. Fully standard compliant EEI definition, and it keeps being fast.
• Basic block and gas metering is solved elegantly modeled after RISC-V’s standard control-flow integrity extensions (chapter 23).

Performance

The performance comparison you see on our initial announcement benchmark still apply. And yes, this is standard compliant RISC-V.

We have further made another ~10-20% improvements around our crypto benchmarks, but those newer results currently remain unpublished and subject to change.

Security

Being standard compliant has enormous advantages. In particular, we’re able to integrate Spike, RISC-V’s official testsuite and simulator. This directly gives us additional coverage. Technically, Spike can also be integrated into the legacy PVM ISA and PolkaVM through the transpiler, but in that case, it cannot be a full test, because transpiler to recompiler part remain untested, and only the recompiler part is executed on-chain.

A standard ISA that has undergone significant industry scrutiny also means that unlike PVM ISA, it’s less likely to have unexpected design issues.

Hardware

Being standard RISC-V also allows us to explore running on a real hardware. This is much harder (if not possible) to do on the legacy PVM ISA, as one generally cannot reuse an existing open source RISC-V CPU design.

In fact, one of our community member is already exploring this direction, for which you can join our Matrix room to learn more.

Trademark

RISC-V is a trademark of RISC-V International, and they’re pretty clear that only standard compliant implementations can refer themselves as “RISC-V”. Per their FAQ:

If an implementation was based on the RISC-V specification but includes modifications beyond this framework, then it cannot be referenced as RISC-V.

The RISC-V community historically quite dislikes non-conformant implementations. It’s contrary to RISC-V’s goal, and leads to unnecessary fragmentation. This is also partially the reason why for PVM2 / JAR Chain, we moved away from PVM and tried hard to see if it’s possible to be both standard compliant and performant. Our results showed that we can.

On the other hand, PolkaVM, being a non-conformant implementation, currently still advertises itself as:

PolkaVM is a general purpose user-level RISC-V based virtual machine.

We want to note that this is technically a trademark violation.

[Onepebble]

Blows me away that no developers is interacting with your threads, regardless of their believes… what you are doing is a net positive to the ecosystem, and i highly support the conversation.

[sorpaas]

Blows me away that no developers is interacting with your threads

Probably just in the closed circle here.

Our Matrix room is quite active: https://matrix.to/#/#jar:matrix.org

And we actually also have interests from existing JAM implementation teams. Of course, before they receive JAM Prize and before I have their consent, I won’t disclose anything.

[Truth_Bearer]

are original and current PolkaVM developers interacting with you on Element?

I dont use that platform but I think it is PARAMOUNT that they have a healthy dicussion on what you are exposing here.

[sorpaas]

Honestly, we have stopped directly comparing with PolkaVM because it’s just slow in our charts. Our development process also revealed a lot of situations where PolkaVM just only publishes benchmarks that favor themselves, and tries to “cheat” on others. (Check the repository for all the specific performance “tuning” that they’re doing, and independent third-party results showing that they’re 10x slower in some situations.)

A lot of the claims made by JAM is rather a question mark, and my only suggestion is that you should verify it by yourself. Create your own workload (but not using their “specifically optimized” workloads), and run the bench yourself.

We don’t plan to talk with the original PolkaVM developers. Their questionable behavior is what prompted us to fork JAM Chain and launch JAR Chain in the first place. But we’re talking on technical levels with interested JAM implementer teams directly (due to their involvements in JAM Prize, we won’t say more).

[kukabi]

@sorpaas I’ve been following your publications from a distance. I cannot say I’m fully on top of it all, but with all due respect, I find it really hard to understand why you insist on proceeding with your work within the Polkadot ecosystem and community in a way that seems to work against your own interests.

Assuming you are right with your findings, why don’t you choose to just rebrand and move on, and do your own public marketing to the broader blockchain ecosystem? You could still make use of comparisons/benchmarks of course, but calling your chain JAR and your VM JAVM (or worse, PVM2) will only keep you in the shadow of the fellowship, Parity, and JAM, which you clearly don’t want to be a part of.

If you’re trying to influence or benefit Parity/fellowship/JAM devs through your findings, then it doesn’t make sense to me why you should do it for free. And even if you did manage to influence, you are unlikely to receive credit for it due to the ongoing tension. Or if your aim is to establish yourself as the technical authority on this side of the space, it’s not going to happen because you’re building within a “foreign” ecosystem. So it really appears to be a dead end.

In short, I’d like to ask, not rhetorically but genuinely out of curiosity, why are you doing this?

[sorpaas]

We checked legal and we’re actually fully within our rights to name it PVM2. We aren’t referring to PolkaVM.

By the way, we want to note that PolkaVM itself has a trademark violation of RISC-V – it’s a non-conformant implementation, and RISC-V International has been pretty clear that you cannot use RISC-V name at all in that case.

[sorpaas]

@kukabi

In short, I’d like to ask, not rhetorically but genuinely out of curiosity, why are you doing this?

For the rest of your questions: yes, we’re doing this deliberately. Our intention posting in this forum is that Polkadot should have a choice. JAR and JAM are both protocols. Competing upgrade solutions both suitable for Polkadot. And the community should have a choice which one it wants to adopt.

Of course, JAR Chain also has its own marketing strategy. And for this we cannot explain more in this forum to avoid breaking any rules. But if you are “genuinely out of curiosity”, you’re welcome to join our Matrix room where we actually discussed the reasoning.

[sabona]

Interesting!

[Onepebble]

I think we have all been in the sidelines on this, I applaud the effort, but the communication tone is hard to take, I agree with You and think the ecosystem would benefit from having this kinds of efforts. Decentralization is max friction and when it comes to techs challenging the status quo, tribalism starts… ok that started before, but you get the point @sorpaas is making.

Just the number of views on the post indicates that there is no much traction from the community on this, sadly so.

[Gr33nHatt3R]

Moderator note: General reminder to everyone: technical disagreement and criticism are welcome, but please keep the discussion focused on the claims, benchmarks, design choices, and tradeoffs. Avoid speculating about motives, intentions, good faith, or personal character. Let’s keep this thread constructive and centered on the technical topic.

[Cyrill]

@Gr33nHatt3R

Avoid speculating about motives, intentions, good faith, or personal character.

@sorpass stay on topic. The human is responsible for generated code anyways, not the AI model, attribution or no attribution doesn’t change that.

[sorpaas]

@Cyrill

The human is responsible for generated code anyways, not the AI model, attribution or no attribution doesn’t change that.

I agree. It’s only fair to compare on the technical merits. Not blind trusts on AI or not-AI. And this is what enforces our points and make PolkaVM’s view more wrong.

• JAR/JAVM (standard RISC-V) is 2x faster than PolkaVM.
• Our blob size is also 20% smaller than PVM ISA.

The entire PVM ISA that you spent years developing is unnecessary. The standard RISC-V is simply better in both aspects we care about.

We have seen no refutations on that so far, but only from @koute’s rumbling about the fact that we used AI (and implying that they didn’t and therefore more secure, which we also just found out that’s false).

[Gr33nHatt3R]

Moderator reminder: Please stay focused on the technical claims and remove any personal accusations about ethics, motives, good faith, or character. This thread has already received a moderator reminder on this point.

[sorpaas]

See also: PolkaVM's use of AI and Claude