This content comes from a recent English live broadcast by PolkaWorld, where we invited Acala's CTO Bryan to reveal the progress of JAM together. After a year of anticipation, JAM is finally going to present itself in a more concrete way this June. So we invited Bryan to share with everyone and allow more people to gain insights into what JAM really is.
Kristen: What is your role in JAM now? What is the atmosphere like in the JAM developer community? What has your personal experience been like?
Bryan: I am Bryan, from Acala. Currently, I am leading a small team dedicated to developing the JAM client for the JAM Prize. There are currently about thirty teams involved in the entire JAM project, and everyone is collaboratively building the JAM protocol in a very decentralized manner. We have established the JAM DAO to coordinate and organize, and we have held two or three offline meetups. To be honest, everyone is doing a fantastic job; we collaborate, set tasks together, share resources, and solve various problems. The entire process is very fun and rewarding, and co-building JAM with these people is a wonderful experience.
Kristen: Is JAM a complete rewrite of Polkadot? Will it completely replace the existing system?
Bryan: JAM stands for 'Join-Accumulate Machine.' In simple terms, it is an 'internet machine.' JAM is built on the foundation of Polkadot and carries all of Polkadot's functions, making it a significant upgrade of Polkadot. It is a 'new version of Polkadot' redesigned and reconstructed from scratch.
Once the JAM mainnet is officially launched, the Polkadot relay chain will be replaced by the JAM chain. However, all parachains, including system parachains and community parachains, can seamlessly migrate to the JAM chain without needing any additional changes. For users, this process is a smooth transition, and there will be no differences in usage.
Kristen: So how long do you think it will take for JAM to be fully implemented? What are the critical parts that are still missing? What important milestones can we focus on next?
Bryan: To be honest, such an epic project is indeed difficult to provide an accurate timeline for. But roughly speaking, the gray paper is expected to be finalized in the next quarter, at which point we will have a clear understanding of the entire protocol and architecture. After that, it will be about specific development and implementation work.
Ideally, we hope to have some relatively mature clients in about six months, at least to launch the test network (testnet) and possibly even the mainnet, but I cannot confirm this yet. Some teams are already sharing the runnable testnet client binary files, but these are still only part of JAM itself. Just like Polkadot without parachains is not very meaningful, JAM itself also needs 'services' to support its ecosystem. So our current focus is on developing JAM's server SDK and also building the 'CoreChain Server,' which can be used to run parachains. This is another key milestone—once this is complete, parachains can migrate or run directly on JAM. Meanwhile, ecological developers can also use JAM's SDK to develop other types of services and build the decentralized applications they want.
Kristen: It does sound like a massive undertaking. How many people are currently involved in the development of JAM? How are they collaborating?
Bryan: I am not sure about the exact number, but I estimate that there are about fifty people participating. You can check greypaper.com, where there is a client section showing the number of teams currently developing the JAM client, which seems to be over thirty. Some are individual developers, and some are small teams, so together it is roughly over fifty people. We have some public communication groups and private collaboration channels. Everyone discusses the gray paper content, the specific implementation of JAM, how to build test networks, compatibility of multiple clients, and other technical details.
We have also created the JAM DAO, and we are currently participating in the on-chain governance of Polkadot, which is also part of our exploration of how to collaborate more efficiently.
Kristen: So, are most of the developers participating in the development of JAM members of the Polkadot Fellowship?
Bryan: Not yet. In the future, as more people participate in the JAM Prize, many will naturally join the Fellowship. But for now, there may only be around five or ten people directly involved in building JAM in the Fellowship.
Kristen: Understood. So will JAM be released in phases? When can we see the first version online? What features will it include?
Bryan: Yes, the JAM will be released in phases. The first to be released will definitely be the testnet. We will have some public testnets available for everyone to try and deploy some things. The testnet may go through several versions of evolution before finally launching the mainnet. Once the mainnet is online, it will basically be finalized.
Unlike the current Polkadot, which is designed to be a continuously self-upgrading system, the relay chain undergoes a major upgrade every few months, but JAM is not designed that way—once the protocol is finalized, it will be fixed. Of course, the client may have performance optimizations later, but the JAM protocol itself will not change after the gray paper is officially finalized.
Kristen: Got it. Is JAM's testnet called JAM Toaster?
Bryan: JAM Toaster is a supercomputer built by Parity, equipped with thousands of CPU cores, used to simulate a complete JAM test network. It may also be opened to the public as a testnet, but I cannot confirm that right now.
But of course, anyone can run a testnet and open it up to form a public testnet, ultimately seeing which testnet is most used.
Kristen: Understood. So what will the migration process look like when JAM officially goes online and transitions from the current Polkadot system?
Bryan: Actually, we have already started this migration work. Because the JAM chain is ultimately intended to replace Polkadot's relay chain, the current Polkadot Fellowship is gradually migrating the core functions originally on the relay chain, such as staking, transfers, governance, etc., to the system parachain (like Asset Hub). This is the first phase of the migration goal—to ensure that user operations occur on the parachain and no longer rely on the relay chain.
Once this phase is complete, the entire relay chain will become a 'transitional layer,' and users will no longer interact with it directly. At this point, when we replace the old relay chain with the new JAM chain, we will only need to 'swap' the underlying chain.
All existing system parachains and community parachains will switch from connecting to the old relay chain to connecting to the JAM chain starting from a certain block, while the rest of the operation mode remains unchanged.
Therefore, from the user's perspective, there will basically be no perception: the parachain you are using remains the same, and wallets and exchanges do not need to perform any additional operations. Only the node operators, such as those providing RPC services, need to upgrade their node software to support JAM. Overall, this migration will be very smooth, and users will hardly need to worry.
Kristen: It does sound like a seamless migration. Once JAM is fully online, how much of a performance improvement will there be? How much can costs be lowered for developers? Can you give a rough idea?
Bryan: It is currently difficult to quantify this accurately because the entire system has not yet fully run. The gray paper contains some performance estimation data, but I cannot recall it now. If anyone is interested, they can check the gray paper. But it is certain that the performance improvement will be very significant. For example, Polkadot currently uses WebAssembly to execute code, while JAM will switch to RISC-V. We chose RISC-V because it is faster and has a simpler structure.
Moreover, the design goal of JAM is to support 341 cores, and I remember that Polkadot currently has over 100, although I cannot recall the exact number. However, it will certainly increase significantly, and each core's execution capability will also be stronger, thus enhancing overall scalability and concurrency. Finally, as the supply of cores increases and resources become richer, the costs for developers will significantly decrease, and the 'price' of core will naturally become very friendly.
Kristen: So has there been any calculation of how much it would cost developers to develop on JAM?
Bryan: This is actually very difficult to estimate. The JAM gray paper does define the protocol and infrastructure, such as how to operate, how to charge (Gas), how to collect Gas fees, etc., but it does not define the economic model. It provides a mechanism for cost-sharing, such as how multiple servers share resources and bear costs, but it does not specify how costs should be priced or how to sell core (execution core), nor does it design specific details for purchase mechanisms like auctions.
Currently, the more likely approach, as I mentioned before, is that we are migrating the existing system parachains from being linked to the Polkadot relay chain to being linked to the JAM chain. These system parachains, such as the one currently responsible for auctioning core on Polkadot, will likely continue to perform similar functions on JAM.
So, the mechanism will continue the current approach—although the current coretime mechanism is not perfect, we are already discussing how to optimize it internally. The design of this mechanism is still evolving, and we encourage everyone to join in now, for example, by participating in the Fellowship's RFC (Request For Comment) discussions and expressing their opinions and suggestions on the core sales mechanism, which will be helpful for future directions.
Kristen: I heard before that the performance of PVM is 20 to 50 times that of EVM. Can you tell us what the core differences are between these two virtual machines?
Bryan: PVM (Polkadot Virtual Machine) is a virtual machine designed from scratch for blockchain, with one of the core design goals being efficient operation. Although EVM is also designed for blockchain, performance was not prioritized in its initial design.
For example, EVM is somewhat like JavaScript—easy to write, with a low entry barrier. But if you need to create a system with particularly high performance requirements, no one would choose to use JavaScript; everyone would use languages like Rust or C++. In the same way, PVM is like Rust, performance-oriented; while EVM is more like JavaScript, easy to use but with many limitations. Therefore, our goal in designing PVM is to break out of the various limitations of EVM and build completely around performance.
Kristen: Since PVM is based on the RISC-V architecture, and we are now seeing Ethereum also moving in a similar direction, what do you think about Ethereum rewriting its virtual machine? What does this mean for Web3?
Bryan: Well, I'm not an Ethereum core developer, so I'm not sure why they are doing this specifically. But from an outsider's perspective, the answer seems pretty clear: it’s because EVM performance is no longer sufficient. If you switch to a better-performing virtual machine, such as one based on RISC-V, performance could theoretically improve by 10 to 20 times, and Gas costs would significantly decrease, which is of course a good thing. Additionally, there is increasing research on RISC-V in the blockchain field, and tools and ecosystems are gradually improving, so this path now seems very feasible. Since there are virtually no obvious downsides and it can improve performance, why not give it a try?
Kristen: So why didn't we use RISC-V directly before?
Bryan: Actually, PVM is not the standard RISC-V but a specially customized version of RISC-V for JAM. This means that if you have a regular RISC-V program, it cannot run directly on PVM; you need to use specific tools to convert it into a format suitable for PVM. We do this because the gray paper defines PVM very clearly, and PVM is designed entirely around the JAM architecture, with all the registers, instruction set design, and so forth considered for JAM.
We are currently developing the JAM client, conducting extensive testing, and iterating and optimizing based on test feedback. Thus, the current PVM specification is not yet finalized; it will continue to evolve with practice. Another ongoing task is to build a Gas model for PVM. This means we are accurately measuring the resource consumption of each instruction to establish a fair and reasonable charging mechanism, which is nearly impossible to achieve on WASM (WebAssembly) because its abstraction layer is too high and its measurability is too poor. Therefore, Parity decided to abandon WASM and choose a RISC-V-based PVM, which is for better control and efficiency. Of course, there are still many unresolved issues, and we believe that a good solution will eventually be found, but it will indeed require ongoing investment of time and research.
Kristen: So do you think the RISC-V based Polkadot PVM will go online earlier than Ethereum's RISC-V virtual machine? From a developer's perspective, will Polkadot become a 'testbed' for Ethereum applications?
Bryan: It is entirely possible. In fact, I do not know how long it would take for Ethereum to upgrade to RISC-V because it also has to consider backward compatibility and deal with many historical burdens, making the upgrade particularly complex. In contrast, Polkadot's upgradability is much better; for example, our parachain is currently running on WASM and can be directly upgraded to run on the RISC-V virtual machine. We do not need to run WASM or EVM in RISC-V like Ethereum; this method is feasible but will be very inefficient. Of course, technically, EVM can also run in the RISC-V virtual machine, but it will be very slow. As for Ethereum, they are unlikely to ask all old contracts to provide new RISC-V bytecode, which is almost unrealistic, so how they will solve these problems is still unclear. But it is certain that the challenges for Ethereum in this upgrade will be very significant.
Kristen: I see. I also have a term that is quite difficult to understand, which is 'coreplay.' What is its relationship with PVM?
Bryan: That's a good question. Let me briefly review the background. An important breakthrough achieved by JAM is supporting 'decentralized non-blockchain applications.' Currently, most smart contract platforms heavily rely on the structure of blockchain, and all programs are designed based on the concept of blocks. For example, in current blockchain systems, you cannot write an infinite loop program—because it will run out of Gas, and the transaction will fail. On JAM, you can write a program that runs indefinitely. This means the program you write does not need to know about the concepts of 'blocks' or 'block time limits.' Although you still need to pay for Gas, the program itself does not need to be aware that it can only execute for 6 seconds or needs to be executed in fragments; it just needs to run, liberating developers from the constraints of programming—no longer needing to break down a resource-intensive task into 50 smaller tasks to execute in different blocks.
On JAM, you can run the program all at once. The 'coreplay' server behind JAM will automatically handle 'cross-block' execution for you. Here’s how it works: when the program is about to reach the execution time limit of a block, coreplay will automatically 'suspend' the program—essentially saving the memory data to the Data Availability Layer, which is like freezing the program. When the next block arrives, it will restore the memory from where it left off and continue running, just like how your computer can resume from sleep mode. Thus, the coreplay program written by developers can be 'block-transparent'—you just need to write code, and the background will automatically handle these 'pause' and 'resume' operations.
Kristen: So can I understand it this way: if PVM is a computer, then coreplay is the software running on this computer?
Bryan: You can understand it this way, but more accurately, coreplay is more like an operating system, while JAM is the 'hardware.' The programs you write are the application software running on this operating system.
Kristen: The Web3 Foundation has committed to invest ten million dollars to support the development of JAM validator clients. The first milestone is to be completed in June. Why are there as many as 38 teams developing almost the same functionality?
Bryan: That's a very good question. First, client diversity is very important. Currently, the client ecosystem of Polkadot is not ideal; over 90% of validator nodes are running Parity's official client. This means that if there is a bug in the official client, the entire network can only follow it, which is actually risky. Therefore, we hope that in the future, no single client's market share exceeds 33%. This way, if a particular client has a problem, other clients can still operate normally, preventing a total network failure, as they are independently developed clients, and the probability of encountering the same bug is very low, greatly improving the reliability of the network.
Additionally, JAM aims to be as decentralized as possible, and we do not wish to say, "Only one team can create a client," as that clearly does not align with the spirit of Web3. Of course, the foundation did not initially expect that so many teams would sign up to develop—38 teams are participating, which is indeed an "unexpected surprise." Although not every team can complete all five milestones, even if they drop out midway, much of the code will still be valuable—because everyone is writing in different languages, some people may just want to use a specific language to connect to JAM, and that unfinished code may still help. Even if using the same language, multiple implementation versions can allow users to choose the version that suits them best, such as having fewer dependencies, better performance, or a more active community. The core of blockchain is decentralization, and decentralization often means that redundancy is necessary—we cannot run all nodes on a single server. Similarly, client implementations should also be diverse and redundant; perhaps not all code will be ultimately used, but this is a necessary cost to achieve true decentralized collaboration.
Kristen: It sounds like this incentive is really strong. Can you tell us more specifically? For example, how much reward can a team receive for completing all milestones?
There are a total of five milestones, and the maximum reward for each milestone is 100,000 DOT, so a team can receive up to 500,000 DOT in rewards. However, it should be noted that this reward pool has a total limit, and operates on a first-come, first-served basis, which encourages everyone to participate early and push forward quickly. At the same time, we have set up four different development language groups, with each language group allocated a different reward pool, encouraging the use of non-mainstream languages (like non-Rust or Java) for client development. This mechanism can incentivize some people to choose less popular languages. Furthermore, since rewards are distributed according to milestones, even if a team cannot complete all five stages, they can still receive corresponding DOT rewards for completing the earlier milestones. We hope that most teams can at least complete the first or second milestone.
Kristen: Understood. So can new teams still join the JAM Prize program now?
Bryan: Yes, as long as there is a balance in the reward pool, you can join at any time. However, I must remind you that this is a first-come, first-served model. Joining late may face the risk of rewards being exhausted, but joining late also has its advantages. Early teams have already hit many snags, and the gray paper has now been updated to version 0.66 (it was initially released at 0.4), having undergone many revisions. If you join now, you can directly develop based on a relatively stable version without having to constantly adjust your code to follow gray paper changes.
Kristen: I see. So to conclude our program, let's talk about the future. What impact do you think JAM may have on the entire Web3 ecosystem? What changes or disruptions might it bring?
Bryan: Well, this question is indeed not easy to predict, but I can say that the potential of JAM is enormous. Polkadot has already made some achievements in scalability issues, but it has not yet resolved many other core problems. JAM was born to fill these gaps, and its potential lies not only in building truly decentralized applications but also in supporting a whole set of decentralized application ecosystems. For example, Polkadot currently has parachains that can communicate via XCM, but the actual usage threshold is relatively high. However, in JAM, by supporting synchronous composability, we no longer need the traditional concept of 'chains.' In the future, JAM can also support many non-blockchain service nodes—making the entire system more flexible and powerful.
Many application logics that were previously difficult or even impossible to realize on-chain can now be implemented. For example, we can achieve complex interactive logics like 'cross-service flash flow,' which other chain platforms currently cannot do. Of course, to truly unleash the full potential of JAM, we need not only individuals to build new chains or services but also the entire industry to collectively think: how can we leverage the new capabilities provided by JAM to solve existing problems? How can we integrate JAM into existing architectures to better serve developers and users? This is not just the responsibility of a single project; it is a collective effort needed by the entire Web3 industry to achieve true transformative change.
Kristen: That's awesome! Well, that's all for today's program. Thank you very much to Bryan for the wonderful sharing, and thanks to all the audience for their participation and support for PolkaWorld. We will continue to pay attention to JAM's development, and we welcome everyone to follow Bryan, Acala, and PolkaWorld for the latest updates on Polkadot and JAM. Thanks again, and see you next time!