Last month, another group of developers and students completed their study of Web3 at the Polkadot Blockchain Academy (PBA) in Lucerne, Switzerland! Gavin personally attended the graduation ceremony and brought blessings and visions to everyone on graduation day! At the same time, several implementation teams of the JAM protocol also shared their journey in JAM and their deep understanding of the JAM protocol with the graduates at the event!
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 relatively long, and PolkaWorld will release it in two parts. This article is the first part, which mainly involves the following content:
JAM Implementation Team Introduction
Why join the 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-term and medium-term goals?
What will the Polkadot migration path to JAM be like?
If you really want to achieve Web3, the only option now is Polkadot and JAM
Read on to learn all about it!
JAM Team Introduction
Jay: Welcome to the Academy event in Lucerne! Today we have a great group of audience friends here. Now we enter a very important part of the Academy - in-depth discussion of the JAM project. Today we have invited a very wonderful group of guests. Next, I will hand over the time to Kian Paimani to introduce the guests and start the discussion. Please look forward to it!
Kian: Thank you everyone! For those friends watching the live broadcast in the classroom, you should already know most of the guests. But for the online audience, let’s do a simple self-introduction and let each guest talk about which team they are in and how they participated in the JAM project. Then I will hand the microphone to Tomek.
Kian
Tomek: Hello everyone, I am Tomek, I am from Fluffy Labs. About eight months ago, we decided to implement the JAM protocol in TypeScript. This implementation is called Typeberry. During the development process, we also had a goal to improve the development experience of other JAM teams, so we are also actively building toolchains related to JAM.
Kian: Why is it called Fluffy Labs?
Tomek: At that time, I wanted to take an interesting name, because many companies like to name themselves with serious mathematical concepts. Fluffy Labs can also remind people of Fluffy Labrador (fluffy Labrador dog). In fact, our stickers have a dog drawn on them, which is to reflect a relaxed and interesting atmosphere.
Daniel: Hello everyone, I am Daniel. I work in the jamixir team, and we implement JAM in the Elixir language. There are only Luke and I in our team. I started doing this about a year ago, after the PBA course. I attended the PBA course in Hong Kong. In order to better understand JAM, I learned and did it at the same time, and I also shared some JAM-related content on Twitter, hoping to let more people know about this project. Of course, we know that there is still a long way to go before JAM can be truly put into production, but this stage is very interesting.
Maciej: Hello everyone, I am Maciej, I am in the Graymatter team. We are also building JAM implementations in Elixir, but our team is slightly larger, with four people, but they are all doing it part-time. I would also like to share a point of view with you here: participating in JAM development does not necessarily require full-time investment. You can participate in your spare time, such as doing lightweight client development or doing related tools, which is suitable for all different types of people to participate.
We are also very clear that since we are doing it part-time, the speed will definitely not be as fast as a full-time team, but we hope to go as far as possible, and also actively cooperate with other teams, such as sharing tools, test sets, etc., the purpose is to make the entire agreement more robust. As for my personal reason for joining JAM, it is because I believe it will become the future of Polkadot. JAM can provide a higher level of abstraction and open up new possibilities that were impossible to achieve in the past.
Alistair: Hello everyone, I am Alistair, currently working as 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 everyone! To add, I am Kian, and I am also in the Graymatter team, serving as a project manager. I usually participate in JAM development part-time. My main motivation is to deeply understand this agreement by participating in the initial two milestones, so as to lay the foundation for more participation and contribution opportunities after JAM is officially launched in the production environment in the future.
Why join the JAM protocol for development?
Next, I would like to ask you to talk more about why you chose to join JAM, what is your specific motivation? Why do you think it is worth investing?
Tomek: For me and my team, at first, we were actually thinking about doing it part-time, purely because we thought it was very interesting. I used to work at Parity and worked on Polkadot. After taking a break, I found that the JAM project was a good way to return. I can use the knowledge and experience I have accumulated in the past to return to the ecosystem. After I shared this idea with some friends, they were also very interested, so later we decided to invest more full-time, that's probably it.
Maciej: Teaming up with Kian was not accidental, but also because we are very aligned in motivation. I also feel that it is necessary to learn the JAM protocol, because it will definitely be very important in the future. Even if my main job is different from this at the moment, I know 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 Polkadot development, I feel it is my responsibility to understand and be able to answer these questions, and the best way to do this is to do it myself, build it, and 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 to achieve in the past. If I didn’t believe in its potential, I wouldn’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 think are the interesting aspects of JAM?
Alistair: I initially got involved because someone asked me about JAM-related matters, so I participated. As for the interesting aspects of JAM, I think the data availability design of JAM is extremely attractive, and I can't wait to witness its application scenarios.
If you ask me, what is JAM for? In addition to being an extension of Polkadot, more deeply, the complexity of the Polkadot protocol has exceeded the scope of a single person's understanding. Therefore, one of the original intentions of writing the Gray Paper is to formulate a unified protocol specification for at least a part of Polkadot, so that it can be understood. 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 eventually look like.
Tomek: Sorry, I would like to add something. From an engineering point of view, the JAM project is really attractive. You can get a complete protocol specification (although it is still being improved), you can choose any programming language you like to implement it, and you can also be incentivized through the "JAM Implementation Award Program", so even if you don’t fully agree with the JAM concept at the moment, this open technical challenge itself is extremely attractive.
Daniel: My story started with PBA (Polkadot Blockchain Academy). When I graduated, I thought about doing something related to Polkadot in the future, but the direction was undecided. Just as I finished PBA, the JAM program was launched, forming a perfect opportunity with the award incentives. However, the award is just a by-product - even if you don'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 invaluable.
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 I got involved is because I firmly believe in Gavin's core Web3 vision that he proposed a long time ago: we need a truly decentralized, permissionless, and attack-resistant system. The so-called blockchains now, whether Ethereum or others, are far from meeting this standard. And JAM may be the first real opportunity in human history to make this happen, so I sincerely want to participate and become the creator of all this, and I am also very happy to work hard here with everyone.
Daniel
Kian: That's great. After listening to everyone's background introductions, it is worth noting the diversity of our group. As an observer, I am delighted to see both Polkadot "veterans", like Alistair, who has been writing code since the Ethereum era, and newcomers like Daniel and others who have come out of the PBA. I hope this can encourage everyone 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, or three years ago are now implementing the JAM protocol themselves. As long as you work hard, there are opportunities.
Daniel: I would also like to add that we are still in a very early stage. This road is very long. It is not a 100-meter sprint, but a marathon. We have probably only run the first kilometer, and there are more than 40 kilometers to go. So, it's not too late to join now.
Maciej: Yes, definitely don’t hesitate because you think it’s “too late”. There is still a lot of work that needs everyone to complete together.
JAM Development Status? 38 Teams, 15 Languages, No Boss, No Orders?
Kian: Very good. Daniel, you just mentioned some other teams and the JAM community. Can you talk more about it? For example, what is the atmosphere of the JAM community now? What are the benefits of so many unrelated people collaborating on development? What are your personal feelings?
Daniel: Actually, I think the design of the JAM rewards program is really clever. It motivates people from all over the world, with different backgrounds, to develop independently around the same blueprint (Gray Paper). Everyone does not copy each other, nor 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, each team started to be able to generate blocks themselves and send the generated blocks to other teams for verification to check whether they meet the specifications. They don’t know the code details of each other, but they can verify each other, which is very exciting in itself. Of course, sometimes small bugs are found, and everyone goes back to troubleshoot their own problems. This is how the community atmosphere slowly formed. We also plan to hold a JAM Experience event in Lisbon in May this year, and plan to launch the JAM testnet at that time (although whether it can be achieved as scheduled is still a challenge). Another thing worth mentioning is 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, PB-level storage, and TB of memory to simulate real network pressure. Different implementations will be interconnected in it, and the scene will be extremely spectacular.
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 - the goal is not to put all versions into production, but to cultivate a community of experts. Just like the existing technical Fellowship of Polkadot, JAM chose to establish this knowledge network before the protocol went online to lay the 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 agreement, and be able to independently develop tools and promote ecological development in the future. If only a few people understand, the entire ecosystem is fragile. Therefore, we must pass on knowledge in order to truly guarantee future success.
Maciej
Kian: I also mentioned in the lecture this morning that the important role of the current Polkadot Technical 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 pre-deployed in terms of knowledge decentralization. The maintenance and upgrade of JAM in the future will be completely out of the control of a single organization, and I think this is very remarkable.
What are these 38 development teams doing? What are their short-term and medium-term goals?
Let’s talk about the future. What goals do each development team hope to achieve in the next year in terms of JAM and their team as a whole? For example, what short-term and medium-term goals do you hope to achieve?
Tomek: Then let me talk first. Regarding JAM, I sincerely hope that there will be a stable running testnet within a year. I think this goal is achievable. As for our own team, the programming language we choose is not the fastest, so it may be difficult to exceed Milestone 3 (corresponding to Kusama-level performance). However, we recently discovered a new path: for example, there is no need to develop a high-performance PVM compiler ourselves, but to use the local code compilation capabilities of other languages. Therefore, our goal is adjusted to complete the second milestone (basic function implementation), and then we may turn to developing a browser light client to provide access to the JAM ecosystem.
Daniel: Our team uses the Elixir language. It is still a question whether we can support Milestone 5. I believe we 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 the upper-level logic control and management. I believe Elixir is very suitable for this.
My plan is to stay in the JAM ecosystem for at least the next ten years. Because after JAM is completed, there are too many things to do: build various services on it, and help others develop based on JAM. It's like entering a whole new world. And, I really like this 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 continue to be maintained.
Maciej: I also agree with Daniel's point of view about Elixir. I myself only started participating in the JAM project in the last month, so I am still in the stage of quickly learning and getting familiar with it. To be honest, there was a lot of information 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 challenge of the sharding architecture - and these are the directions I have been researching and developing in Polkadot 2.0 for a long time. So next, I hope that I can not only help my own team, but also share my knowledge with more JAM teams to help 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 the initial ELVES running 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 these experiences.
Alistair: Of course, I am also looking forward to it! For me, my focus is: what functions can we put into the first version of JAM, and which ones 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 nodes can be reduced by 40% - that is to say, under the same hardware conditions, the processing capacity of the system can be increased by 40%. This is a big improvement, but I am not sure if this can catch up with the launch of the first version, and I guess many developers don't actually want to catch up hahaha, because that would make the work to be done even heavier when they come up.
Kian: Speaking of this, I want to ask Alistair a question: You just mentioned that JAM will have version upgrades. So can you explain what the future upgrade route of JAM will be like? Because many people will be confused at the beginning, Polkadot can be upgraded on the chain, but JAM does not seem to particularly emphasize the on-chain upgrade mechanism. What is the difference between these two? If a major upgrade is really to be carried out on JAM in the future, and the gray paper even needs to be re-formulated, or even a hard fork, what would be the reason?
Alistair: In fact, the current Polkadot, strictly speaking, only supports on-chain governance upgrades at the runtime level. The underlying changes such as consensus algorithms still require hard forks, which are not much simpler than Bitcoin. What about JAM? In the future, it will indeed have its own hard fork management model. This is a new topic in the Polkadot ecosystem. Perhaps, the technical Fellowship will play a more important role at that time, after all, they are already very important in the runtime upgrade on Polkadot. JAM may also have its own “Fellowship branch” to be responsible for future large-scale changes, but to be honest, we haven’t finalized how to do it yet.
Alistair
Kian: I heard Gavin mention in an interview before that it seems that a certain hard fork or major version update of JAM in the future may involve Quantum Resistant Crypto. Alistair, you know more about this, can you tell me if this is true? Or did I hear it wrong?
Alistair: Well, well, I don't think there is a very urgent need for quantum-resistant encryption right now. But the important thing is - we must prepare a fork version that can be switched at any time. We are now reviewing the various cryptographic primitives in Polkadot to see which ones can be easily replaced with quantum-resistant ones. Some places are very simple, such as replacing the elliptic curve signature with a standardized lattice-based signature is relatively easy, but for example, the VRF (Verifiable Random Function) we use in ELVES and Sassafras is not so easy to use quantum-resistant encryption, and we may have to switch to Randomness Beacon or the DKG-based method I mentioned before. We are seriously thinking about these issues, such as whether we can try it on Kusama first. Overall, if a fully quantum-resistant system is launched directly on JAM, the performance will be somewhat degraded. But more importantly, you have to be prepared with a fork version that can be switched at any time, even if it is not enabled immediately in the short term.
Daniel: So, if you want to be quantum-resistant, you have to sacrifice performance? Is there no way to be both fast and quantum-resistant?
Alistair: However, some protocol optimizations can alleviate the impact. For example, using hash-intensive algorithms may maintain speed, but will increase bandwidth consumption. For example, 100KB of zero-knowledge proof (SNARK) originally executed on the chain can be migrated to the off-chain service for processing, so that the on-chain performance is not affected. The real pain point is the expansion of signature volume - 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. All functions must be extended 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 to judge whether a hard fork is necessary: as long as it can be proved that the upgrade will not bring systemic risks, and will only improve system performance or security, everyone can generally accept it, and it is unlikely that the community will be severely divided.
What will the Polkadot migration path to JAM be like?
Kian: So that is to say, it is this design that makes the probability of JAM needing a hard fork extremely low. Then I want to ask everyone present, what do you think the future upgrade and migration path of the existing Polkadot system and various Parachains (parallel chains) will be like? Of course, it hasn't reached that point 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 can be made clear that Parachains have a place on JAM. Every time I talk about JAM, I will emphasize this point. Existing parallel chain teams will have a way to migrate to JAM, and there will be dedicated services to support the operation of parallel chains.
As for how to migrate specifically, this is more difficult. Some people are discussing whether Regenesis (chain restart) is needed? Is it necessary? There is no conclusion yet, and everyone is still analyzing various advantages and disadvantages. What is certain is that the technical Fellowship will participate, and may even require some form of governance decision, but it is not easy to draw a conclusion now.
Alistair: Yes. The most basic idea is to first develop a Core Chain Service that can support the operation of parallel chains on JAM. Many of the existing Parachain nodes are built based on FRAME and use the Cumulus framework. As long as they are slightly adapted, they can theoretically continue to run. This is the first step - to make it logically run. As for the details of the migration, such as how to migrate data and how to maintain the state, this is another matter and a very interesting technical challenge, but that is something to be considered in the next stage.
Kian: I would also like to add. 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 certain: as seamless as possible and reduce the impact.
Maciej: Yes, in fact, we are also experiencing similar things in the current Polkadot 2.0 upgrade process, 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 JAM migration at that time, and may also allow us to discover and solve some potential problems in advance.
Kian: It is worth noting that Polkadot has many upgrades in the remaining time of this year. The core is to migrate some functions from the relay chain to the system chain, such as Asset Hub. Doing so not only improves the protocol itself, user experience, and developer experience, but also prepares for the future JAM. We are gradually "emptying" the relay chain to make it as lightweight as possible, so that it can be replaced smoothly and painlessly when it is replaced with JAM in the future.
If you really want to achieve Web3, the only option now is Polkadot and JAM
Finally, I have an open-ended question, and then I will hand it over to everyone to ask questions: Do you have any ideas or feelings about JAM that you would like to share? For example, what excites you the most, or what are your expectations for the future? Open-ended question, anyone can talk about it.
Tomek: This question is too open, haha. Then let me talk from an engineer's point of view first. Now is actually a very unique opportunity. As everyone said before, the versatility of JAM far exceeds the existing Polkadot architecture, that is, we can directly migrate the current parachains there and they can still operate normally.
But the more important question is: besides migrating existing parallel chains, what else can we do? JAM opens up many new possibilities for us, such as - do we still have to use the form of "chain" in the future? Can there be new models? What 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 yet. Although Parity and Gavin are making a JAM SDK, JAM itself runs on PVM, and developers are free to choose their own development framework, as long as they can compile 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 a development framework suitable for their own applications, which will become the foundation of the JAM ecosystem in the future.
Tomek
Daniel: My idea may be more philosophical. If you really believe in the ideal of Web3 - decentralization, resistance to censorship, and the chain can run completely by itself without relying on any centralized entity, then I want to say that, as far as I can see, only Polkadot and JAM are still truly insisting on doing this. Look at the others, such as Ethereum. The current Ethereum is actually "stuck", the technology is also backward, and the community can hardly promote major upgrades anymore. 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 the second-layer (L2) expansion of Ethereum, such as Base and Arbitrum, are actually centralized, and are essentially contrary to the ideal of Web3.
If you really want to do Web3 in the true sense, the only option now is 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, completely agree. The dream of Polkadot and JAM is to be able to truly build decentralized, censorship-resistant protocols. Although there are still some challenges in the design, such as some places that still need more exploration and innovation, we will continue to push forward.
Maciej: My feeling is this: As the first sharded blockchain prototype, although many of our designs are correct, we have also realized along the way that some places can be done better. JAM is just an opportunity for us to clear the accumulated "technical debt" over the 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 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, the logic is simple and the architecture is clear. This will be much easier for developers and the community to understand. In fact, not only blockchain, 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 actually don't know what new things can be achieved on JAM in the end. But we hope that the various abstractions and generalizations in JAM can open up new possibilities. For example, Gavin proposed a "Coreplay" idea back then, which is a new idea that goes beyond the existing parachain. Although that idea was not officially made into a PR (Pull Request) at the time and the version was relatively old, if you are interested, you can dig into the RFC repository of the Polkadot Fellowship, where there are some sources of inspiration.
Maciej: I would also like to add a sentence, which may be a bit "venomous". If the JAM ecosystem is ultimately just a replica of parallel chains, it will be a complete failure. What we are looking forward to is that more new things can be developed based on JAM! Coreplay is a part that I am particularly looking forward to, and I sincerely hope to see it truly applied on JAM in the future.
Kian: Okay, thank you everyone for sharing! Then, I will take the microphone and walk around the venue, and everyone can ask questions freely!
The following is mainly some community Q&A questions, PolkaWorld will release it tomorrow!
