JAM

JAM is a technical upgrade to Polkadot that started in early 2024 and, at the time of this writing, is being finalized with a formal specification. Once enough teams have implemented it, it is intended that the Polkadot L1 will upgrade itself to the JAM protocol, while the L2s and the rest of the ecosystem remain intact.

I have talked at length about JAM in Demystifying JAM. This chapter is merely a summary of that article.

In-core and On-chain

To understand the nuances and motivations for the JAM protocol, we must first take a step back and recall that a standard blockchain is similar to a single-core CPU that can only process a single Block of work every x seconds, as explained in Sequential Blockchains. Then, recall that Polkadot’s architecture is quite analogous to a multi-core CPU. This is because in Polkadot, there are two types of execution that the L2 blocks experience:

• First, they are re-executed by a subset of the L1 validators (first ~5, then ~30 out of a 1000-set of validators, under normal conditions — see the ELVES paper for more info).
• Then, all L1 validators will perform a small amount of work that recognizes that a new L1 block has been re-executed enough times and is valid.

These two types of execution in Polkadot are called in-core and on-chain execution respectively. Note that what is executed in-core is as secure as what is executed on-chain. This is the main magic of the ELVES protocol.

The first motivation of JAM is to recognize that the in-core/on-chain execution environments are useful primitives for doing broader Trustless computation towards Web3, not just securing other blockchains. Therefore, in JAM, L2s are given complete freedom to do whatever they want in-core and on-chain.

In fact, no such thing as an L2 exists in JAM, and it is instead called a service. We use the word L2 here for simplicity.

Data Availability Accessible to Users

As it stands now, the Data Availability in Polkadot (and likely in Ethereum) is only used to store L2 block information. This is a bit ironic, as we know from Storage that the lack of storage primitives other than the blockchain State is one of the bottlenecks of building more Web3 applications (other than more DeFi blockchains).

Similar to the on-chain/in-core execution environment, JAM is recognizing that Data Availability is another powerful primitive that should not only be used towards serving L2s, but should be accessible to developers as a primitive to store any information that they want in it. We already noted that the analog of an L2 in JAM is called a service. In JAM, services have free access to the Data Availability layer, to write whatever they want to it, and read whatever they want from it.

The cost overhead of storing data in Data Availability is much less than the State, as the history of the data is not kept in the Data Availability.

Lean Protocol

Another motivation for JAM is to clean up a lot of technical debt from the protocol and strip it down to its basics. This is a desirable property that is also being pursued in other major blockchains that think about their long-term sustainability, such as Ethereum with the Lean Consensus roadmap. Having a lean, well-defined protocol will significantly make the protocol more Trustless by making sure many teams and people have the knowledge to understand and maintain it.

While Polkadot managed to implement a fairly complex protocol, likely the first of its kind in achieving heterogeneous sharding with shared security, it has also accumulated a lot of technical debt and complexity in the protocol. JAM is a major step towards cleaning that up by removing a lot of the unneeded complexities from the core protocol, moving them higher up to the application layer.

Examples

JAM has no notion of a Rollup or Parachain, Governance, and even tokens and balances. All of that is assumed to be handled by higher-level services running on top of JAM. The protocol only cares about providing secure in-core/on-chain execution primitives, plus access to Data Availability to developers building services on top of it. These services could be anything and are not in any way restricted to being an L2/Rollup.

Continuous Execution

Finally, JAM is leveraging two of its assets:

• A new lean and register-based VM based on RISC-V (called PolkaVM)
• Access to Data Availability for storing large transient data To allow, likely for the first time, the ability to write continuous code to be written in a blockchain and be executed fully onchain. By continuous, we mean a block of code that can take a minute or an hour to complete, and as the developer, we don’t have to think about splitting this block of code into multiple small chunks that fit in a block.

Under the hood, JAM does the following:

• Execute the continuous code for as long as the gas permits within a block
• Store the intermediary registers of the virtual machine in Data Availability
• Resume it on the next block
• Repeat this process until terminated.

Needless to say, DOOM has been used as an example to demonstrate this¹.

This is a full circle to our comments on hosting any applications on the blockchain STF in an earlier chapter: Hosting Any Application In Blockchain STF. Moreover, even then we pointed out that the comparison between how different blockchain protocols host continuous execution is not always apples to apples. To the best of my knowledge, JAM is the only protocol that allows arbitrary long workloads to be executed onchain (assuming ELVES convinces you that the execution in-core is as Trustless as on-chain). Cardano has demonstrated running DOOM on an L2 environment as well, but this has significantly different properties to what JAM is doing:

• The actual game-related work is all happening on an L2, which is in fact a state-channel, and only the opening and closing part of it is recorded and processed by Cardano L1 validators².
• In contrast, in JAM, the game is actually being executed by JAM validators, the efficient scaling method of sharding execution while retaining shared security.

Footnotes

1. Search for topics like “DOOM on Polkadot JAM” to learn more and see demos of this new technology in action. ↩

2. Running Doom on blockchain: a landmark moment for Cardano and Hydra - Input | Output ↩