Happy to take it on. We have the financial resources to defend our rights.
And we’ll be happily publishing everything we can publish in the process. The community has been asking for transparency from W3F for a long time. This will actually be a good opportunity to reveal more information.
Let me remind you, PolkaVM just recently had to fix a security bug and yank two consecutive releases 0.32.0 and 0.33.0.
Yes, you heard it right – this has gone into PolkaVM releases. No CVE number. No public communication. If someone has been really using PolkaVM in production other than Parity, they’ll be in a bad time. Fortunately we don’t have any yet.
Since you’re talking about legal and you seem to be claiming that “the code quality in the PR I linked above is nowhere near PolkaVM” – better back it up by objective data. Otherwise, this breaks comparative advertising law: comparative advertising is allowed as long as it is objective and factual. We backed up all our claims by benchmarks and hard truths, which even Jan himself has to (partially) confirm.
Fortunately, we aren’t as pity as you and won’t throw random legal threats around. (:
If you had actually read our post, you’ll know that the post’s main thesis is that, based on our benchmarks, we believe the PVM ISA itself is unnecessary. It wasn’t about PolkaVM vs JAVM, or JAM Chain vs JAR Chain. But since you have to make it, then here’s a comparison chart we made a few weeks ago.
By the way, unlike PolkaVM which has been in development for three years, we’re a young project that was started 3 months ago. We haven’t made any release yet, and are of course still in development. The difference for us is: we don’t try to convince the community about any of our safety / security criteria through blind trusts to any humans or organizations. As you seen from the bugs PolkaVM has to pull from releases, and critical security issues on Polkadot, blind human trust is extremely fragile. Instead, we prove our security through our architectural design and objective means. We have an important principle for JAR: correct by construction. If you say 49% of our inspirations come from JAM, then 51% of our inspirations actually come from seL4 microkernel and formal verification. This is why we spent a long time designing our capability-based system and the data-flow principle.
Even Vitalik mentioned this as a primary trend in blockchain development:
Provably bug-free Ethereum. This is a goal that all cybersecurity researchers would have thought is absurd and impossible, up until roughly 6 months ago. Now, it’s on the cusp of being possible, thanks to AI-assisted formal verification. So we should be frontrunners in doing this.
I think you’ll see more and more chains taking up approaches similar to us and what Vitalik mentioned, and less and less chains will have the anti-AI approach that Polkadot right now is experiencing. Hell, you may even see JAM Chain adopting JAR’s capability-based system or data-flow principle some day, if not for the fact of JAM Prize that, with the now already closing M1 milestone verification, they’ll now make implementors’ time miserable if they do large overhauls like this.
Anyway, in blockchain, you’ll eventually have to be open source anyway. Keeping things closed source like JAM is doing right now won’t fend out “competitors”, but will just make your own stuff not meaningful in the meantime. So even logistically speaking, we’ll always welcome competition, we always publish our design as early as possible, and we don’t fear to develop in the open. (But as I said, JAR is coinless and it does not directly compete with “coin-ful” chains, but you seemed to be want to label us as a “competitor”, so we’ll be happily taking on the hat.)