
Written by: PolkaWorld
What is Gavin Wood's JAM? Why should we care about it? This article is published by Polkadot community member goku on X. He starts from the essence of the problem and analyzes it from the perspective of Ethereum to Polkadot to help you understand the concept of JAM more deeply.
Read on to see the collated version of PolkaWorld!
How did we get here – what’s the problem?
Our understanding of the nature and significance of blockchain is still evolving and deepening today.
Today, blockchain is like a trustless decentralized computer with verifiability, but at the same time, it has some limitations that we are still exploring.
The way blockchain works is that all transactions are processed sequentially, one after the other. The system first understands the current state, then processes these transactions and updates the state.
While this approach works, it limits the ability to multitask since validators must recheck every transaction, resulting in slower performance.
How can such a system be expanded?
Scaling Up — Vertical Scaling
Synchronous scaling — This is what integrated systems like Solana do.
Extreme optimization of code and hardware
Use faster validators
Improve connection quality
Achieve maximum throughput
But eventually, you may hit a bottleneck.
If you want to stay in Web3, you are likely to hit a bottleneck. Because the barriers to entry are getting higher, more complex, and more difficult to cross. Running a strong validator node is becoming more and more challenging.
So what do you do if you want to stay in Web3 but can’t scale vertically?
You have to scale horizontally -- that is, scale out.

This is the logical way of thinking in Silicon Valley.
Rather than relying on one super powerful system, it is better to have many smaller, weaker systems working together in parallel.
Cosmos is such a way that you can connect to its ecosystem, bring your own security, and expand according to your needs.
What’s the problem? Decentralized security. Different layers of security. Limited interactions between chains.
ICS, ATOM 2.0, the merger of OSMO and ATOM — they are all trying to resolve this fragmentation and bring some consistency.
This way, you can scale out across multiple nodes, parallelize your workload, break it up into small tasks, and assign different tasks to different nodes — sharding execution and data processing, with each shard running under a unified security guarantee.
This is Polkadot.
How Polkadot scales
Emerging as the multi-chain successor of Ethereum. Today, Ethereum's Rollup-centric expansion approach is following the path of the Polkadot parachain model.
The difference lies in the way they execute and implement these Rollups.
Polkadot puts different parachains (similar to Rollup) in a shared security network and expands through unified security guarantees. Compared with Ethereum's Rollup model, Polkadot's validators not only store data, but also re-execute Rollup to ensure consistency and security.
In addition, these Rollups exist in the same ecosystem, each with its own independent state and governance, and although they share the same security guarantees, they are still independent of each other.
Although Ethereum is a Rollup model, smart contracts share the same environment, so they are more connected, but still independent individuals. This continued fragmentation still exists. Cross-chain communication still faces friction, is complex to process and slow, and is far less efficient than native transactions.
But the Polkadot approach also has its limitations. It is a high-performance, low-cost machine in terms of throughput, data availability, and execution. But only parachains or Rollup chains - a specific form of chain - can choose to join this machine. Data is stuck in a certain shard and cannot exist between multiple shards at the same time, nor can it be easily migrated. This is not true expansion and lacks coherence. This also makes the user experience, development experience, and synchronizing data between different Rollups more complicated.

This is the problem facing Polkadot in a nutshell:
Early fragmentation was too severe
The use of Polkadot core is too single and fixed
DOT has a single usage scenario, which is to pay for block space fees.
Wouldn’t it be great if we could achieve sharded scalability without forcing teams to use a particular layer 2 or parachain? What if they didn’t even have to make a choice?
JAM was born out of these insights, as a single shared secure Rollup model is not the only way to scale.
The key to achieving real breakthroughs lies in further abstracting and generalizing Polkadot’s infrastructure.
JAM and KERNEL analogy
The kernel is like the core manager of computer operations:
Manage system resources (CPU, memory)
Enables communication between hardware and software
No restrictions on what software can be run - that is the user or application's decision
Make sure everything runs smoothly and efficiently
So, sum up JAM in one sentence.
It is the kernel at the heart of Polkadot’s hardware, allocating its resources and allowing any program or system to run in its shared security and sharding environment, with minimalistic and unrestricted execution.

If you were to explain what JAM is to a middle school student?
Ethereum, and most other blockchains, are like a server in your basement.
Polkadot is like cloud computing with shared security where you rent first and run your chain.
JAM is a serverless -> cloud-based chainless application.
Serverless architecture changes the way cloud applications are built today -> developers only need to focus on writing code.
Polkadot x JAM
Polkadot is a Rollup chain with parachains. In JAM, it's just a service. It's a hyperscale platform with massive computing power. It doesn't lock application or smart contract developers to one place like Moonbeam, Arbitrum, or Optimism. It's more like working in any cafe, not in one office.
How powerful is JAM?
Polkadot has 1023 validators, 3 validators per core — 341 cores in total.
Polkadot’s Data Availability (DA):
Before asynchronous support: 20Mb/s
After asynchronous support: 67Mb/s
In JAM: 852Mb/s
This is 85 times the current Polkadot computational load, which is targeted at 300,000 TPS (based on a transaction size of 250 bytes) and aims to achieve over 1.5 million TPS in the long term through optimization.
So, technically speaking, JAM will host services that secure blockchains — and not just blockchains. After all, blockchains are just one type of decentralized, trustless digital service, and smart contracts are another.
So, does JAM just add smart contracts?
Yes and no.
Gavin explained that JAM allows developers to deploy any type of code, not just smart contracts, and have it run on the blockchain with the guarantees of trustlessness and permissionlessness — from financial applications to voting and governance systems that handle large amounts of value.
There is no need to deal with gas fees, blocks, or auctions.
Why is it more powerful than any smart contract chain?
It will have more computing power and storage space. While still taking advantage of smart contracts, its speed and storage capacity are expected to be millions of times faster, truly improving speed, storage, capacity, and cost efficiency.
How is this achieved technically?

In JAM, services have two pieces of code, while standard smart contracts only have one.
One piece of code runs on-chain, like a smart contract. Another piece of code runs off-chain in the "core".
JAM has 341 cores - similar to CPU cores, supporting parallel computing. As chip technology develops, its scalability will become stronger and stronger.
The computations in the core run code similar to on-chain smart contracts, but are faster and run in parallel.
Unlike on-chain code, it cannot change the blockchain state. Instead, it utilizes a massive 2 PB decentralized data lake that can read and write data efficiently.
Since JAM Core processes data faster and handles larger data sets, it is no longer reasonable to charge per transaction like Ethereum does.
JAM will be able to operate on an entirely different scale – a system that goes beyond blockchain, with versatility and broad application.
How about the service?
JAM's decentralized storage can work with a 2 PB data lake.
Data can be marked for separate storage.
Data is retained for approximately 28 days, after which it is automatically deleted or re-stored.
For long-term storage, a separate decentralized solution is still needed. This decentralized storage could use blockchain, smart contracts, or other methods. Or it could be more conveniently implemented through JAM as a service at the lowest user level. This makes long-term data storage easier to manage efficiently.
So what does this entail?
dApps without transactions are a new breakthrough in crypto
Throughput could exceed Solana’s 850MB/s while solving the synchronous composability problem, another innovation in multi-chain environments and Web2
Any code, any program can run on it
JAM can choose to process synchronously, allowing the core to be shared across the shard network. Now applications between shards can interact synchronously within the same block.
How is the development of JAM progressing?
The first implementations are expected to go live in the fourth quarter of this year, and a 10 million DOT implementation prize is currently underway, see http://graypaper.com for details.
Gavin Wood has been on a global tour since the beginning of this year to introduce JAM to future developers, visiting Buenos Aires, Berkeley, Zurich, Tokyo, Seoul, China, Singapore, Brussels — and coming up in India, the US, Asia, and Europe.
He even returned to Silicon Valley, where he and Vitalik were rejected before Ethereum launched.
Now, he has been invited back.
Why has this journey taken so long? Why is decentralization so difficult?
Yes, computers have gotten faster, blockchains have improved, and databases have evolved. But the key difference is whether the system is based on traditional ideas like Bitcoin and whether it is truly decentralized.
Indeed, if you have only one node or 42 nodes in the same datacenter (like ICP), the throughput can be easily increased. Use a Gigabit network connection, lots of memory, and have 2-3 nodes handle most transactions.
However, if your network is decentralized, this is much harder.
This is why Ethereum, despite all its genius, continues to struggle to scale — it’s only now getting to the stage that Polkadot was at a few years ago. Meanwhile, Polkadot is taking another major step forward, pushing the innovation frontier once again. Expect other networks to gradually move closer to Polkadot in the coming years.
Solana is now entering the L2-centric phase that Ethereum started two years ago.
