Join the PolkaWorld community and build Web 3.0 together!
Last month, another group of developers and students completed their Web3 studies in Lucerne, Switzerland through the Polkadot Blockchain Academy (PBA)! Gavin personally attended the graduation ceremony and brought blessings and visions to everyone on graduation day! At the same time, multiple implementation teams of the JAM protocol also shared their journey in JAM with the graduates at the event, as well as their deep understanding of the JAM protocol!
Whether you are a developer who wants to join JAM, or an ordinary user who is optimistic about the future development of JAM, this article is worth reading and learning!
This content is quite long, PolkaWorld will publish it in two parts. This article is the first one, mainly covering the following contents:
JAM Implementation Team Introduction
Why join JAM Protocol for development?
JAM development status: 38 teams, 15 languages, no boss, no orders
What are these 38 development teams doing? What are their short- and medium-term goals?
What will the migration path from Polkadot to JAM be like?
If you really want to implement Web3, the only options now are Polkadot and JAM
Keep reading to learn what it’s all about!
About the JAM Team
Jay: Welcome to Academy in Lucerne! We have a great audience here today. Now we are entering a very important part of Academy - a deep dive into the JAM project. We have a great panel today and I would like to hand it over to Kian Paimani to introduce the panelists and start the discussion. Stay tuned!
Kian: Thank you everyone! For those of you watching the livestream in the classroom, you should already know most of the guests. But for the online audience, let's do a brief self-introduction and let each guest talk about which team they are in and how they got involved in the JAM project. I'll hand the microphone over to Tomek.
More and more
Tomek: Hi, I'm Tomek from Fluffy Labs. About eight months ago, we decided to implement the JAM protocol in TypeScript, and this implementation is called Typeberry. During the development process, we also have a goal to improve the development experience of other JAM teams, so we are also actively building a JAM-related toolchain.
Kian: Why is it called Fluffy Labs?
Tomek: I wanted to come up with a fun name because a lot of companies like to name their products after serious mathematical concepts. Fluffy Labs can also remind people of Fluffy Labrador. In fact, there is a dog on our stickers, just to reflect a relaxed and fun atmosphere.
Daniel: Hi, I'm Daniel and I'm on the jamixir team, we're implementing JAM in Elixir. It's just me and Luke on our team. I started working on this almost a year ago after finishing the PBA course. I took the PBA course in Hong Kong, and I'm learning as I go along to get to know JAM better. I'm also sharing some JAM-related content on Twitter, hoping to get more people to know about the project. Of course, we know there's still a long way to go before JAM can really be put into production, but it's a very interesting stage right now.
Maciej: Hi, I’m Maciej, I’m in the Graymatter team. We’re also using Elixir to build JAM implementations, but our team is slightly larger, with four people, but we’re all part-time. I’d also like to share a point of view with you: you don’t have to be a full-time employee to participate in JAM development. You can participate in it in your spare time, such as doing lightweight client development or related tools. It’s suitable for all kinds of people to participate.
We are also aware that since we are doing it part-time, our speed will definitely not be as fast as the full-time team, but we hope to go as far as possible, and we are also actively cooperating with other teams, such as sharing tools, test sets, etc., in order to make the entire protocol more robust. As for why I personally joined JAM, it is because I believe it will be the future of Polkadot. JAM can provide a higher level of abstraction and open up new possibilities that were not possible in the past.
Alistair：Hi everyone, my name is Alistair, and I am currently the Chief Scientist at the Web3 Foundation. My main job is to support the design of JAM from a theoretical level.
Kian: Okay, thank you! I am Kian, and I am also a project manager in the Graymatter team. I also participate in JAM development part-time. My main motivation is to participate in the two initial milestones to gain a deeper understanding of the protocol, so as to lay the foundation for more opportunities to participate and contribute after JAM is launched in the formal production environment in the future.
Why join JAM Protocol for development?
Next, I would like to ask you to elaborate on why you chose to join JAM, what is your specific motivation, and why you think it is worth investing in?
Tomek: For me and my team, we actually thought about doing it part-time at the beginning, just because we thought it was interesting. I used to work at Parity and Polkadot. After taking a break, I found that the JAM project was a good way to return to the ecosystem with the knowledge and experience I had accumulated in the past. When I shared this idea with some friends, they were also very interested, so later we decided to devote ourselves to it full-time. That's about it.
Maciej: It is not accidental that I teamed up with Kian, but also because we are very consistent in motivation. I also think that it is necessary to learn the JAM protocol because it will definitely be important in the future. Even though my main job is different from this at present, I am well aware of the forward-looking nature of this technology. I often have PBA students or other developers ask me questions about JAM. As someone who is still involved in the development of Polkadot, I feel it is my responsibility to understand and be able to answer these questions, and the best way is to do it myself, to build it, and to read the gray paper and the various design details in it. Of course, I also believe that JAM can bring new features that were impossible in the past. If I don’t believe in its potential, I won’t spend time investing in it. It is precisely because I think it is worth looking forward to that I am willing to invest time and energy.
Kian: Alistair, would you like to share what you find interesting about JAM?
Alistair: I got involved because someone asked me about JAM. As for what’s interesting about JAM, I think its data availability design is very fascinating, and I can’t wait to see its application scenarios.
If you ask me, what is JAM for? In addition to being an extension of Polkadot, the complexity of the Polkadot protocol is beyond the scope of a single person's understanding. So one of the original intentions of writing the Gray Paper is to develop a unified protocol specification for at least part of Polkadot so that it can be understood by people. If it can be understood clearly, the system can be better optimized. Therefore, the goal of JAM is to achieve higher performance than the current Polkadot. This is a very ambitious protocol, and I am very much looking forward to seeing what it will look like in the end.
Tomek: Sorry, I want to add one more thing. From an engineering perspective, the JAM project is really attractive. You get a complete protocol specification (although it is still being refined), you can choose any programming language you like to implement it, and you can also get incentives through the "JAM Implementation Award Program", so even if you are not fully convinced by the concept of JAM yet, this open technical challenge itself is very attractive.
Daniel: My story begins with PBA (Polkadot Blockchain Academy). When I graduated, I was thinking about doing something related to Polkadot in the future, but the direction was undecided. It just so happened that I had just completed PBA and the JAM program was launched, which formed a perfect opportunity for the award incentive. However, the award is just a by-product - even if I didn't win the award, the knowledge accumulated in the process, the collaboration with top developers such as Gavin Wood, and the thorough understanding of the underlying protocol are priceless treasures.
Because after JAM is built, there will be many JAM-based services that can be developed, and people who understand the underlying details will definitely have a huge advantage. The reason why I joined in is that I believe very much in the core vision of Web3 that Gavin proposed a long time ago: we need a truly decentralized, permissionless, and attack-resistant system. The so-called blockchain now, whether it is Ethereum or others, is far from meeting this standard. And JAM may be the first time in human history that there is a real opportunity to make this happen, so I want to participate from the bottom of my heart and become the pioneer of all this, and I am also very happy to work here with everyone.
Daniel
Kian: That's very well said. After listening to everyone's background introduction, it's worth noting the diversity of our group. As an observer, I am happy to see both Polkadot "veterans" like Alistair who have been writing code since the Ethereum era, and new forces like Daniel and others who have come out of PBA. I hope this can encourage all the students present and tell you that this road is not insurmountable. People who were sitting in the classroom like you a year ago, two years ago, and three years ago are now implementing the JAM protocol with their own hands. As long as you work hard, there is a chance.
Daniel: I would also like to add that we are still in a very early stage. This road is long, not a 100-meter sprint, but a marathon. We have probably only completed the first kilometer, and there are more than 40 kilometers to go. So, it is not too late to join now.
Maciej: Yes, never hesitate because you think it is “too late”. There is still a lot of work that needs to be done together.
The current state of JAM development? 38 teams, 15 languages, no boss, no orders?
Kian: Very good. Daniel, you just mentioned some things about other teams and the JAM community. Can you elaborate on that? For example, what is the atmosphere of the JAM community now? What are the benefits of so many unrelated people working together to develop? What are your personal experiences?
Daniel: Actually, I think the design of the JAM reward program is really smart. It encourages people from all over the world and different backgrounds to develop independently around the same blueprint (Gray Paper). Everyone does not copy each other or interfere with each other, but they are all working towards the same standard. If everyone strictly follows the specifications, these independent implementations can eventually be interconnected to form a truly decentralized network.
We have already started to see this process. A few months ago, teams started to produce blocks and send them to other teams for verification to check if they meet the specifications. It is very exciting to be able to verify each other's code without knowing the details of each other's code. Of course, sometimes some small bugs are found, and everyone goes back to troubleshoot their own problems. In this way, the community atmosphere is slowly formed. We are also planning to hold the JAM Experience event in Lisbon in May this year, and we plan to launch the JAM testnet at that time (although it is still a challenge to be able to do it on time). It is also worth mentioning that we are also building a data center called JAM Toaster to prepare for future large-scale testing. This supercomputing cluster is equipped with hundreds of cores, petabytes of storage and terabytes of memory, which can simulate real network stress. At that time, different implementations will be interconnected in it, which will be a spectacular scene.
Tomek: By the way, many people may not know that there are currently 38 teams publicly participating, covering about 15 programming languages. Some people may question whether so many implementations are needed - in fact, the goal is not to put all versions into production, but to cultivate a community of experts. Just like Polkadot's existing technical fellowship, JAM chose to establish this knowledge network before the protocol goes online to lay a talent foundation for future upgrades.
Maciej: Yes, one of the core purposes of the award is to promote ecological prosperity through knowledge decentralization. PBA, JAM Prize, and Fellowship are all for the same goal: to let more people understand, participate and truly understand the protocol, so that they can independently develop tools in the future and promote ecological development. If only a few people understand, the entire ecosystem is fragile. Therefore, we must pass on knowledge to truly ensure future success.
Matthias
Kian: I mentioned this in my lecture this morning. The important role of the current Polkadot Technology Fellowship is to prevent any single company from becoming a development bottleneck or knowledge monopoly. JAM has gathered more than 40 teams and hundreds of developers through the award program, and has made advanced deployments in the decentralization of knowledge. In the future, the maintenance and upgrades of JAM will be completely out of the control of a single organization, which I think is very remarkable.
What are these 38 development teams doing? What are their short- and medium-term goals?
So let's talk about the future. What goals does each development team hope to see JAM and their team as a whole achieve in the next year? For example, what goals do they hope to achieve in the short and medium term?
Tomek: Let me talk about it first. Regarding JAM, I sincerely hope that we can have a stable test network within a year. I think this goal is achievable. As for our own team, the programming language we chose is not the fastest, so it may be difficult to exceed Milestone 3 (corresponding to Kusama-level performance). However, a new path has been discovered recently: for example, there is no need to develop a high-performance PVM compiler by ourselves, but to use the native code compilation capabilities of other languages. Therefore, our goal is to complete the second milestone (basic function implementation), and then we may turn to developing a browser light client to provide an access portal for the JAM ecosystem.
Daniel: Our team uses the Elixir language, and it is still a question whether it can last until Milestone 5. I believe it can, but it depends on the progress. If we really can't achieve the ultimate performance, we can also use low-level languages such as Rust to handle the most performance-intensive parts, and let Elixir focus on upper-level logic control and management. I believe Elixir is very suitable in this area.
My plan is to stay in the JAM ecosystem for at least the next ten years. Because after JAM is completed, there are still many things to do: build various services on top of it and help others develop based on JAM. It's like entering a whole new world. Moreover, I like the way of working now: no company, no boss, no customers. We are a community of like-minded people, collaborating freely and sharing with each other, which is the best. I hope this atmosphere can be maintained forever.
Maciej: I agree with what Daniel said about Elixir. I have only been involved in the JAM project for the past month, so I am still in the stage of rapid learning and familiarization. To be honest, the amount of information was really overwhelming at the beginning, but I am slowly sorting it out.
I have observed that most teams are currently focusing on the first milestone (basic state transition function) and are about to face the core challenges of the sharding architecture - and these are exactly the directions of my long-term research and development in Polkadot 2.0. So next, I hope to not only help my own team, but also share my knowledge with more JAM teams, helping them understand the sharding mechanism, how to do ELVES (execution environment), and how to make the various parts of the system work together. If all goes well, we should be able to see preliminary ELVES operation results on JAM within a year. We have accumulated a lot of optimization experience in the Polkadot field in the past few years, and now it is time to pass on this experience.
Alistair: Of course I am looking forward to it! For me, my focus is: what features can we put in the first version of JAM and what have to be pushed to the future. For example, the Tenderbake team was discussing the DKG (distributed key generation) protocol two weeks ago. If JAM can introduce threshold cryptography technology in the first version, the workload of the validator node can be reduced by 40% - that is, under the same hardware conditions, the processing power of the system can be increased by 40%. This is a big improvement, but I'm not sure if this can catch up with the first version, and I guess many developers don't want to catch up, haha, because that would make the work harder at the beginning.
Kian: At this point, I would like to ask Alistair a question: You just mentioned that JAM will have version upgrades. So can you explain what the future upgrade path of JAM will be? Because many people will be confused at first, Polkadot can be upgraded on the chain, but JAM does not seem to emphasize the on-chain upgrade mechanism. What is the difference? If JAM really needs to be upgraded in the future, and the gray paper needs to be re-formulated, or even hard forked, what will be the reason?
Alistair: Actually, strictly speaking, the current Polkadot only supports on-chain governance upgrades at runtime. The underlying changes such as consensus algorithms still require hard forks, which is not much simpler than Bitcoin. What about JAM? In the future, it will indeed have its own hard fork management model, which is a new topic in the Polkadot ecosystem. Perhaps, by then, the technical Fellowship will play a more important role, after all, they are already very important in the runtime upgrades on Polkadot. JAM may also have its own "Fellowship branch" to be responsible for future large-scale changes, but to be honest, we have not yet finalized how to do it.
Alistair
Kian: I heard Gavin mentioned in an interview before that a future hard fork or major version update of JAM may involve quantum resistant cryptography. Alistair, you are more knowledgeable about this, can you tell me if this is true or did I mishear it?
Alistair: Well, I don't think there's a urgency to get quantum-resistant crypto right now. But the important thing is - we have a fork ready to switch to at any time. We are currently looking at the various cryptographic primitives in Polkadot to see which ones can be easily replaced with quantum-resistant ones. Some things are simple, such as replacing elliptic curve signatures with standardized lattice signatures, but for example, the VRF (verifiable random function) we use in ELVES and Sassafras, it is not so easy to use quantum-resistant cryptography, and may have to switch to randomness beacons or the DKG-based approach I mentioned earlier. We are thinking about these issues seriously, such as whether we can try it on Kusama first. In general, if you launch a fully quantum-resistant system directly on JAM, there will be a certain performance degradation. But the more important thing is to have a fork ready to switch to at any time, even if it is not immediately launched in the short term.
Daniel: So if you want to be quantum-resistant, you have to sacrifice performance? There is no way to be fast and quantum-resistant?
Alistair: However, some protocol optimizations can mitigate the impact. For example, using a hash-intensive algorithm may maintain speed, but will increase bandwidth consumption. For example, a 100KB zero-knowledge proof (SNARK) originally executed on the chain can be migrated to an off-chain service for processing, so that the on-chain performance is not affected. The real pain point is the expansion of signature size - mainly consuming block space rather than computing resources.
Tomek: It is worth noting that JAM, as a minimalist protocol, does not natively include tokens and governance mechanisms, and all functions must be expanded in the form of services. Therefore, future upgrades will focus on improving the underlying protocol, such as switching to quantum-resistant encryption, or improving the efficiency of validators and reducing their workload. Moreover, there is a very intuitive standard for judging whether a hard fork is necessary: as long as it can be proved that the upgrade will not bring systemic risks, but will only improve system performance or security, everyone will generally accept it, and it is unlikely that there will be a serious split in community opinion.
What will the migration path of Polkadot to JAM look like?
Kian: So it is this design that makes the probability of JAM needing a hard fork extremely low. Then I would like to ask everyone here, what do you think the future upgrade and migration path of the existing Polkadot system and various Parachains will be like? Of course, we haven't reached that stage yet, but based on your current understanding, can you predict it?
Maciej: I think this question can be divided into two parts. First of all, it is clear that Parachains have a place on JAM. Every time I talk about JAM, I will emphasize this point. Existing parachain teams will have ways to migrate to JAM, and there will be dedicated services to support the operation of parachains.
As for how to migrate, this is more difficult. Some people are now discussing whether Regenesis (chain restart) is needed? Is it necessary? There is no conclusion yet, and everyone is still analyzing the pros and cons. What is certain is that the technical fellowship will be involved at that time, and it may even be necessary to make some form of governance decision, but it is difficult to make a conclusion now.
Alistair: Yes. The most basic idea is to develop a Core Chain Service that can support the operation of parachains on JAM. Many existing parachain nodes are built on FRAME. With the Cumulus framework, they can theoretically continue to run as long as they are slightly adapted. This is the first step - make it logically work first. As for the details of the migration, such as how to migrate data and how to maintain the status, this is another matter and a very interesting technical challenge, but that is to be considered in the next stage.
Kian: I would also like to add one point. As Maciej said, the current goal of Parity and Fellowship is to make the migration process as seamless as possible. Of course, it is still in the early planning stage and the specific plan still needs to be explored. But the direction is clear: as seamless as possible and reduce the impact.
Maciej: Yes, in fact, we are also experiencing similar things during the upgrade process of Polkadot 2.0, such as migrating the functions on the Relay Chain to various services. In this process, we are also accumulating a lot of migration experience. I believe that these experiences will provide a lot of help for the migration of JAM, and perhaps also allow us to discover and solve some potential problems in advance.
Kian: It is worth noting that there are many upgrades to Polkadot in the rest of this year, the core of which is to migrate some functions from the relay chain to the system chain, such as Asset Hub. This will not only improve the protocol itself, user experience and developer experience, but also prepare for the future of JAM. We are "emptying" the relay chain bit by bit to make it as lightweight as possible, so that when we switch to JAM in the future, we can complete the replacement smoothly and painlessly.
If you really want to implement Web3, the only options now are Polkadot and JAM
Finally, I have an open-ended question, and then I'll let everyone ask questions: Do you have any thoughts or feelings about JAM that you'd like to share? For example, what excites you the most, or what you're looking forward to in the future? This is an open-ended question, and anyone can come and talk about it.
Tomek: This question is too open-ended, so let me talk about it from an engineer's perspective. Now is actually a very unique opportunity. As everyone said before, JAM's versatility far exceeds the existing Polkadot architecture, which means we can directly migrate the current parachains to it and it will still work normally.
But the more important question is: what else can we do besides migrating existing parachains? JAM opens up a lot of new possibilities for us, such as - will we still have to use the form of "chain" in the future? Can there be a new model? What kind of new services can be built based on JAM? What's even cooler is that we don't even have a standard framework to develop these services. Although Parity and Gavin are working on a JAM SDK, JAM itself runs PVM, and developers are free to choose their own development framework as long as it can be compiled to PVM in the end. And because PVM is based on the RISC-V architecture, it theoretically supports almost all mainstream programming languages. So, this means that in the future everyone can use their favorite language to define their own development framework that suits their application, which will become the foundation of the future of the JAM ecosystem.
Tomek
Daniel: My idea may be more philosophical. If you really believe in the ideals of Web3 - decentralization, anti-censorship, and chains that can run completely independently without relying on any centralized entity, then I would say that at present, only Polkadot and JAM are still really insisting on doing this. Look at other things, such as Ethereum. Ethereum is actually "stuck", the technology is backward, and it is difficult for the community to promote major upgrades. And those other chains that claim to surpass Ethereum are essentially operated by some centralized companies, and one or two entities can control the situation. Even Ethereum's second-layer (L2) extensions, such as Base and Arbitrum, are actually centralized, which is essentially contrary to the ideals of Web3.
If you really want to do real Web3, the only options now are Polkadot and JAM. Of course, to turn this ideal into reality, more people need to work together. We are working hard to attract more people to join. The more people there are, the faster we can achieve this goal.
Alistair：Yes, I totally agree. The dream of Polkadot and JAM is to build a truly decentralized and censorship-resistant protocol. Although there are still some challenges in the design, such as some areas that require more exploration and innovation, we will continue to move forward.
Maciej: My feeling is this: Polkadot is the first sharded blockchain prototype. Although many of our designs are correct, we have also realized along the way that some things can be done better. JAM is an opportunity for us to clear the "technical debt" accumulated in recent years. We can redesign it in a more abstract and concise way to create a protocol that is truly close to the ideal state.
In addition, some people now think that the Polkadot protocol is difficult to understand. In the future, this situation will be much better on JAM. Because JAM only retains the most core and necessary things, with simple logic and clear architecture. In the future, it will be much easier for developers and the community to understand. In fact, not only blockchains, but all large software systems will accumulate technical debt, but most projects rarely have the opportunity to completely reconstruct. We are now seizing this opportunity to do it right again.
Alistair: I would like to add that we don’t know what new things can be finally realized on JAM. But we hope that the various abstractions and general designs in JAM can open up new possibilities. For example, Gavin proposed the idea of "Coreplay" that year, which is a new idea that goes beyond the existing parachain. Although that idea did not officially become a PR (pull request) at the time and the version is relatively old, if you are interested, you can go to the RFC repository of Polkadot Fellowship, where some inspiration comes from.
Maciej: I would also like to add one more thing, which may be a bit "venomous". If the JAM ecosystem ends up being just a copy of the parachain, it will be a complete failure. What we are looking forward to is to develop more new things based on JAM! Coreplay is a part that I am particularly looking forward to, and I sincerely hope to see it being truly applied on JAM in the future.
Kian: Okay, thank you all for sharing! Next, I will take the microphone and walk around the venue, and everyone can ask questions freely!
The following are mainly some Q&A questions and answers that the community is concerned about. PolkaWorld will be released tomorrow!