The Road to JAM

Tech Talk
1

Dear community,

As we’re approaching the switchover of Parachains finality to a JAM service, we want to share with you the coming technical updates of the four underlying projects:

  1. Launching JAM in production (project: PolkaJAM),

  2. reducing the Relay Chain functionality to only validation of Parachain execution (projects: Minimal Relay aka AHM v2, and Offchain Messaging), and

  3. launching and switching over to the new JAM based finality service (project: Parachain Service).

Some of these might require an upgrade on your side, which we will communicate and provide guides in a timely manner.

Herewith, the project deliverables in more detail:

  1. PolkaJAM:

    • A full node implementation following the Gray Paper v1.0 specification, hardened to the standards a production network demands: robust against malicious peers and denial-of-service attacks, graceful under overload, and safe to restart at any time.

    • An in-browser light-node library so that user-facing applications can access JAM directly and verifiably.

  2. Minimal Relay (AHM v2):

    • Reducing the Relay Chain to a minimal, transactionless coordinator (completing the work done in last year’s Plaza Asset Hub Migration):

      • Parachain registration, channel management, and on-demand coretime ordering move to the Coretime chain, where users will interact with them going forward. A migration guide will map every affected call to its new home, and replacement tooling will support the moved flows.

      • Deposits move with their functionality to the Coretime chain, and vestigial free balances move to Asset Hub.

    • End state: zero DOT on the Relay Chain, no user-callable transactions, and no way to move funds onto it again.

  3. Offchain Messaging:

    • JAM will solely build on a new messaging protocol, which delivers messages entirely off-chain, matching and improving upon the latency of Polkadot-SDK legacy HRMP, without storing them on JAM state. More importantly, this setup paves the road for even lower latencies in the future.

      • The intent is to add offchain messaging as an alternative to on-chain HRMP on Polkadot.

    • This project is part of a larger effort to reduce latency, and in subsequent work we will further reduce messaging latency (target: 100s of milliseconds).

  4. Parachain Service:

    • An audited and hardened code of the Parachain Service, running live on JAM with Parachains producing blocks and exchanging messages on it. The service will be production ready with a prototyped and testnet-demonstrated switchover mechanism.

    • The service will include everything the Relay Chain’s parachain host does today: block validation, code upgrades, key handling, coretime/authorization.

Related work:

  1. JAM:

    • Finalising and auditing Gray Paper v1.0.

    • Launch initial JAM production network, with nodes run by independent operators.

As we move forward with the project, we will keep you informed in this thread. Please make sure to subscribe to get notified. In the following months we will share here support channels, guides and other relevant information for the transition to JAM run as smoothly as possible.

Best,
Parity Technologies

2

Perfect, but the community should demand that what I call the PNE (Polkadot Network Engine), in this case JAM, be easily replaceable — meaning that it should not require a hard fork or other complex processes.

Let me explain: although JAM may seem revolutionary right now, with advances in technology and hardware, I would say it will probably become obsolete in 8–10 years, once ZK technology becomes practical and usable.

I’ve done some research, and with a theoretical ZK-based design, it would be possible to have 1,000 cores for 1,000 validators, along with other advantages.

Therefore, for Polkadot to remain competitive in the future, we need to place strong emphasis on this.

Polkadot must not be optimized for a specific technology but rather for its capacity to mutate.

3

This is not really possible.

You could easily achieve this with JAM, by putting all the proofs into work packages. And yeah for sure, zk will improve, but will the proving ever be real time? Hard to imagine, but let’s see.

4

Basti, the problem with doubting ‘real-time proving’ is that you are evaluating the future based on today’s hardware and algorithms.

5

We will see what the future will bring :slight_smile: But JAM will not prevent anything in the future.

6

ZK and JAM are not mutually exclusive, as Basti mentions you can have proofs in the work packages, then a service’s code becomes mostly the proofs verification, processing messages and not a lot more.

To give an example, I’m prototyping such a system, not because I think JAM needs zk-rollups to scale but because I still see organizations/communities(decentralized or not) as the main users of decentralized infrastructure(we are B2B), and they need/want privacy, that’s why they keep building web2 backends and won’t make the jump to use decentralized technology. There will be huge advantages for organizations to be able to cooperate in a trustless way, but it will take time for them to realize that, so in the meantime I want to meet them in a middle ground, provide an easy to deploy and use backend, an “OS” that in the age of AI pretty much can write its own services for the organization, use PVM off-chain for those private services but also allow parts of them to be “attestatable”, i.e. prove the execution of PVM code on a ZK VM that a JAM service can verify. Those mini private zk-rollups don’t need an ever growing chain of blocks with a byzantine fault tolerant consensus, simpler raft that many databases use works well, anyway most small parachains have a very centralized collator set, still there should be a path for progressive decentralization if the organization ever needs to switch consensus.

7

A collator/workpackage producer can be basically anyone. In the beginning we also had this consensus which allowed anyone to build blocks. This is working, it just introduces more forks etc. But if you don’t have that much traffic and your demand to commit to the global consensus is just driven by certain actions, you can probably run completely without any consensus for committing to JAM.
In the end it all depends on the use case and how you build this. :slight_smile:

8

The 1000 validators/1000 cores I mentioned can’t be achieved with JAM, but with a new protocol based purely on ZK.

Ethereum is also researching a solution based on ZK, so if Polkadot stays on JAM forever, it will become obsolete compared to Ethereum in a decade.

So the PNEs in Polkadot should be interchangeable, like Game Boy game cartridges, to make an analogy.

9

If you include 3 zk proofs into each JAM core, you end up with the 1000 cores you are talking about. I’m not sure why you are saying that this is not possible.

10

How many validators does JAM need per core?

On the other hand, regarding what you’re talking about 3 ZK proofs, it’s not JAM; there’s nothing that says that, nor is it in their specifications.

Furthermore, 3 proofs/core ≠ 3 core

11

In theory, JAM has the same validator vs cores relationship as Polkadot, since the sharding protocol ELVES has only minor changes. We’d an in-depth parameter discussion here:

Intuitively, it should be roughly num_validators * relayVrfModuloSamples = E * num_cores The ELVES paper worked out E=25 but we picked E=30 based upon earlier simulation work, and just retained it for extra security margin. Also relayVrfModuloSamples is defined by validator specs and the protocol, so it increases somewhat in JAM. We’d naively expect every core costs like three validators based upon this, but we’ve a gap between theory and practice..

We’ve done spamening runs with many cores, but not 1/3rd of the validator set. I’ve forgotten the spamening numbers, but they were done on Kusama with its low spec validators and rampant spec cheating. It’s likely there are many protocol inefficiencies too, not only Kusama having weak validators. JAM adopting QUIC should help here eventually, but it’ll take multiple JAM iterations to realise those gains.

Anyways if you ask validators to be 10x more powerful and have more bandwidth, and you somehow enforced this, then we could probably run 1000 cores on 1000 validators on Polkadot today. We do not do that because we want private individuals to run validators, not just institutions, and we want validators in many jurisdictions, some of which have worse bandwidth.

Zero-knowledge could mean many things. It’s clear private transactions implemented by zero-knowledge have become an overall priority. You are seemingly discussing “zk roll ups” in the Ethereum sense, which incidentally only use SNARKs without the zero-knowledge part, and provide no real privacy.

There were many advances in the proof systems of course, but true zk roll ups always have extremely expensive prover time. We’d one major ethereum zk roll up making blocks of 180 tx for more than $20 in Amazon EC2 CPU time.

At 6 seconds, that costs $288k per day, or $105 million per year in CPU time, and that’s only 30 tps for the whole zk roll up. Also, they incurred 10s of minutes in cross chain latency waiting for proofs, but later work should’ve improved parallelisation.

Amazon EC2 is expensive, but you need redundant provers for liveness, and you need to pay those node operators well, so Amazon EC2 costs make a sane baseline.

In other words, if each of 1000 Polkadot validators earns $100k per year then all of Polkadot consts roughly what a single low tps zk roll up costs. After fixing many inefficiencies, this could realistically manage 1 million tps or more. You could pay considerably less or demand much beefier hardware and network too.

Around this, true zk roll ups spend heavily on hardware opportunity costs and hosting, which leave their ecosystem, while our costs are predominantly validator and collator salaries, so more chance those payments stay within the ecosystem.

I do think zk roll ups could’ve cheaper bandwdith costs than parachains or services, but if they have liveness then the bandwidth costs cannot really beat us by that much, again assuming some optimisations on our side.

As SNARKs improved, there exist better non-private SNARK tricks for parachains or JAM services than for Ethereum: If we find a cheap enough storage SNARK, then we could do only the storage proofs in the SNARK, which partially removes the zk roll up bandwidth advantage, but keep the signature verification transparent and batched. We’ve no idea if SNARK have reached the point where this becomes economically viable yet, because doing experiments with altered storage remains complex on polkadot.

In summary, true zk roll ups shall always cost many orders of magnitude more than polkadot cores. If zk roll ups ever catch up, then we can copy only the fastest parts of their proofs that cost us bandwidth, but then do native EC MSMs that still massively beats them.

Polkadot has never had scalability problems. That’s what we do much much better than anyone else.

12

The proofs would obviously be generated off-chain using GPUs or ZK-ASICs, not CPUs. But anyway, I think we’re talking about different things. For the protocol I have in mind, the validator requirements would be minimal, and existing validator hardware would be sufficient.

13

I’m quoted the off-chain costs there. Amazon EC2 is off-chain obviously. The off-chain costs and prover latency are the limiting factors for zk roll ups, well multiplied by the redundancy required by liveness.

Yes, GPUs speed up some proof systems, but not enough to be cost competitive with polkadot. CPU and GPU time both cost money.

These “zk roll ups” use non-interactive proof systems. Polkadot’s ELVES protocol is also a proof system, but an interactive one that invokes heavier assumptions than zk roll ups.

As I said above, Polkadot can open up non-interactive proof techniques, apply what’s useful, and skip what’s costly, or rearrange them to exploit interactivity differently, because we have a much more powerful interactive verifier model that goes way beyond smart contracts. Ergo, Polkadot tx should always be orders of magnitude cheaper than similar zk roll up tx.

The price we pay is optics: They can criticise our heavier assumptions. Our assumptions are similar to what everyone assumes in their consensus though.

Also, I largely ignored latency above, but afaik the fastest deployed SNARKs are Stwo and Barretenberg. Stwo benchmarks focus upon specific primitives, so maybe useful for storage, but less useful for a general purposes. Barretenberg needs more than 1 second of prover time for a single ECDSA signature on a 32 CPU machine, far slower on normal hardware. 1 second is very fast, but not fast enough if you want 1000s of tx in a block every 6 seconds.

14

If you read my comments, what I was criticizing was the rigidity that the JAM protocol could impose on Polkadot, potentially making it harder to accommodate future upgrades involving new technologies. Everything I said about a protocol based on these kinds of technologies was referring to a ten-year horizon, not tomorrow.

15

do you mean that after JAM we would be have difficult time to upgrading? so the JAM is the final version?

16

Hi @burdges, today Polkadot (and Kusama) validators in regions away from Europe are basically penalized by the design of the protocol since latency means they are missing more votes, translating in lower performance and lower era points as they are located quite far from the main european cluster of validators. This in addition to more expensive acces to required hardware and connectivity (sometimes x3), we have already discussed this in the past, for example here, although the situation is more critical today than a few months ago.

The Polkadot active set is mostly composed today of what seems like institutional staking, most independent validators have lost the majority of their organic nominators since the changes implemented this year, including: no more commissions, min self stake (and the incentive), no slashing for nominators and fast unbonding, which reduced staking rewards for nominators, who find a logical alternative in the rewards received from having their own validator nodes with selfstake between 10-100K DOT and enough backing DOT to keep them in the set (~1.3-1.5M). This means nodes previously operated by private individuals have mostly dropped out of the active set and those previously located in diverse geographic locations have ceased to exist or relocated to cheaper locations like Europe or Singapore.

How would this change in JAM (aside from QUIC)?

How do you plan to achieve this?

Will the protocol actually incentivize in any way to have validators in different regions? and independent validators instead of institutions? Otherwise I think it will be very difficult to achieve what you describe above.

17

Hey @florentina57, thank you for the questions. Most of them are not really related to JAM. Because incentivization of validators is not done by JAM. It is done by the upper layers, so by the logic that we describe today as Polkadot.

JAM itself will broadly work as the relay chain today, but even today I would count the behavior you are explaining as bugs. I know that you raised them before, but this is something we need to improve. Maybe JAM is helping there, as it changes the underlying network, but I can not ensure that this will actually make a difference now.

Generally to validator election + incentivization there are some discussions around the staking changes + metanode that will change the dynamics.

18

Maybe @jonas you can comment as well here.
I agree with @florentina57 and Basti that these are concrete issues and they are largely unrelated to JAM. As mentioned, initial discussions are underway regarding broader future of staking, focusing on integration with dotUSD, metanodes serving app, new election mechanism potentially replacing Phragmén and linked to Individuality and the App, and so on, shifting how validator elections and incentives work. So to achieve broader geographic distribution and decentralization, we will need to have proper (upcoming) protocol levers. And there will always be some natural tension on how to guarantee (economical) safety of the active validator set and proper decentralization. I can’t share anything concrete yet and in general it can also be a mix of on-chain and off-chain levers, e.g. via social contract on max number of nodes a validator operates, a decentralization campaign and so on.
All largely unrelated to JAM and again, all yet to be properly defined before being shared with a larger audience. More details will follow in a separate post.

19

Exactly, JAM breaks with the forkless upgrade system.

20

It does not. You can still forkless upgrade services and thus, most of the important business logic. Even today with the relay chain you could not just launch “1000 cores” without doing node side changes.