This content comes from the monthly call of the Polkadot technical Fellowship. The technical Fellowship is a decentralized group of technical experts on Polkadot's chain, including Gavin Wood, who participates in this meeting almost every time and shares his recent main work focus. In the May meeting, he shared the following important progress:
The gray paper version 0.7 will implement all the functions required for network operation.
Audit of the gray paper will begin at the end of July, in preparation for version 1.0
What are Coreboot and Corechains?
Is JAM Toaster mining BTC?
Will JAM issue a Token?
Continue reading to see all the information!
The gray paper version 0.7 will implement all the functions required for network operation.
Gavin: Last month we experienced the first practical experience of JAM and did some preparatory work. Recently, what I've mainly been working on is getting the content of the gray paper to a basically complete state, so it can meet the standards for accepting first-phase candidates. Although the gray paper is not yet version 1.0, and it will need to undergo an audit to reach that level. But our current goal is to achieve version 0.7 first.
Specifically, the goal is to implement all the functions required for network operation in version 0.7, and these functions must also be adapted to the expected usage of the network in terms of performance. We have been developing various services, the most well-known of which is probably the CoreVM service. In the process of developing these services, we have also become more aware of how certain APIs should be modified more reasonably.
If you look at the issues regarding version 0.6 in the gray paper repository, you will find that most of them are not major protocol changes, but belong to the category of 'user experience optimization' improvements — to make it easier for developers to run and debug code on JAM.
For example, a feature I recently added called 'account metadata' introduces information similar to what processes contain in an operating system for service accounts, such as: who created this service (parent service), the last time it completed accumulation, its creation time, etc. This basic information is very helpful for DevOps operations.
I think this is also a small watershed we have stepped out of traditional blockchain logic — we now have to consider the user experience of DevOps users because what we are building is not an ordinary chain, but a 'super internet magic computer'.
Audit of the gray paper will begin at the end of July, in preparation for version 1.0.
In addition to the modifications made to the gray paper, we are also working on some other aspects for the actual PolkaJAM codebase. Some are related to CoreVM, and some are improvements at the tool level. For example, we are creating a command-line tool called JAMtop, similar to an activity monitor, which can now identify CoreVM services and display the content running inside the guest. For instance, when you are running the Doom game, it will clearly tell you that you are currently running Doom; when you are running a video test, it will also show 'running video test', rather than just saying 'running CoreVM'.
We have also made some other supporting improvements. Overall, I still feel that we can push towards version 0.7.0 as planned, although the completion time may be slightly later than I ideally envisioned. But I think we should be able to finish it before the end of the month. It may still require a few days of intensive work, but it's not a big problem.
Next, starting from version 0.7, my idea is to sprint directly towards the goal of 1.0. Originally, we envisioned that the series from 0.7 to 0.8 would make some major changes, such as the service creation process, deployment on Toaster, etc. — these principles are still retained in principle, but I am now inclined not to shove everything into this phase.
I have actually listed some ideas that might be suitable for inclusion in the series from 0.7 to 0.8 (which can be seen in the gray paper repository), but it seems that most of them do not belong to the necessary functions of 1.0 and are more suitable to be reserved for JAM 2.0 or later iterations. They are not core content necessary for using JAM.
So my plan is: once we reach version 0.9, we will start the audit process. Currently, I expect a gap of about one month between each version from 0.7 to 0.8. If 0.7 is released at the end of this month, then by the end of July, we should be able to submit the gray paper for this version to the auditing party in preparation for the release of 1.0.
Of course, the release of the gray paper 1.0 does not mean that there will immediately be a large number of implementations compatible with 1.0, as these implementations also need to go through audits. However, these two processes can proceed in parallel.
That is to say, as long as the client implementations during the gray paper audit are based on version 0.9, they can also start their own audit processes — as long as they are willing to accept adjustments or corrections as needed after the protocol audit is completed.
That's about it, everything is progressing smoothly at the moment.
What are Coreboot and Corechains?
Alice and Bob: I have three questions to ask you next, first about the roadmap: what does coreboot refer to here? Has it been released? Is it something usable now?
Gavin: Well, we actually now call it a 'bootstrap service'. As for the name 'core'... some people like it, and some don't. I don't know if it will be retained when it is truly productized. Right now, it's just a placeholder name in the project repository.
Alice and Bob: So 'core boot' is not really a module in the true sense, it is simply a 'bootstrap service'. What about 'core chains'? Are people already developing it?
Gavin: Bastian has made some preliminary attempts, but I'm not sure how far he has progressed. I remember that after JAM XP, during those few days of the closed-door meeting in Lisbon, he was debugging like crazy. But I feel this is a project that won't progress too slowly as long as you start working on it. Although it may take some time to truly achieve the level of seamless switching like Polkadot, I hope we can prove soon that 'this thing is feasible.' Basti is around too, you can ask him.
Basti: I'm here, and as I said before, it’s not done yet. But I feel that this can be done. The more I think about it, the more I feel that the final implementation should be quite intuitive (please don't take this statement out of context 😅). Because JAM itself already provides many foundational building blocks, like various runtime environments, and those default built-in mechanisms that we don't need to worry about ourselves.
So overall, this shouldn't be too complicated. I'll try to create an initial version that 'works' first, and then iterate based on that. But the initial version may be a 'super hack', and I'll need to polish it into something more presentable later.
Is JAM Toaster mining BTC?
Alice and Bob: Okay, thanks, I've noted this part. Gavin, can you briefly talk about the experience at the Lisbon JAM XP event? How did the teams perform?
Gavin: Those days were quite interesting and fun. We took everyone on a tour of Toaster, and the feedback was quite good. The hardware part of Toaster is progressing well and should be basically completed now. We are now starting to formally deploy code into it, and it feels good. The overall atmosphere of this event was great, and everyone was quite happy and interested in the content being showcased.
During the closed-door meeting, progress on interoperability did not advance much, but shortly after we released the executable file for PolkaJAM, which everyone can use to test their node implementations. Now two teams have reported that they can interoperate with PolkaJAM nodes, which is a very positive signal, indicating that we are steadily moving towards complete interoperability. Although the current chains only achieve the first milestone level of interoperability, the second phase may be a bit more complex, but this is already a good start.
Alice and Bob: I heard that Toaster is particularly noisy and has serious heating issues, and there are even rumors that it's mining Bitcoin — what do you think of this claim?
Gavin: As far as I know, this is not the case. Toaster does not have a GPU, so mining is almost impossible, and it is not an efficient way to use computing power.
Will JAM issue a Token?
Alice and Bob: Okay, so the last question. I can probably guess your answer, but since many people have been asking recently, I still want to confirm: will there be a JAM exclusive token in the future?
Gavin: Well... there is currently no plan for that, but I am indeed often asked this question. I am still thinking about what the significance and role of a token would be if it were to be issued. Right now, I don’t think anyone can clearly articulate its purpose.
Of course, we can't completely rule out this possibility. I've talked to some JAM implementation teams, and they indeed have had similar thoughts in mind. So this cannot be completely denied, but I don't have a clear stance on it right now. You can ask me again in a month, and I might be able to give you a clearer answer then.
I feel that from an economic model perspective, its value proposition is actually similar to that of DOT, and I don't see particularly different aspects.
However, this topic is indeed complex. People have many strong opinions about token economic models, such as: is inflation a good thing or the embodiment of evil? Is fair distribution necessary? Is a founder's background a bonus or completely irrelevant, or even a negative factor?
These questions are very subtle, and we certainly need to treat them sensitively, but they can sometimes become a distraction. So, I feel that these two aspects need to be balanced. As I mentioned earlier, I have not yet seen a particularly convincing reason to support the introduction of a new token.
But one thing I do feel is worth worrying about — Polkadot has always been highly associated with 'parachains', because the Polkadot white paper written eight years ago stated it that way. The new features provided by JAM may very well be overlooked because of this stereotype. If JAM is strictly classified under Polkadot, its powerful features may be overshadowed by the 'Polkadot' brand, causing potential developers to miss its value.
I think we need a convincing answer to this question, but I don't have one right now, and I don't necessarily think 'issuing a new token' is that answer. However, it's a question worth pondering.
This is actually more of a 'brand positioning' issue, or rather, this topic has quietly slipped into the discussion. It's not only about brand awareness but also about 'mindshare' — of course, branding is just a small part of communication.
I believe that JAM can open up many new possibilities, not just for Parity or Polkadot Fellowship, but for the entire Web3 world. So how do we convey this message, helping everyone truly understand the significance of JAM and be willing to invest time in experimenting? This is the problem we need to solve.
What worries me is, as I mentioned earlier, Polkadot is almost synonymous with 'parachains' in the minds of many people. If we want people to realize that Polkadot is not just parachains, but also new architectures like Services, CoreVM, CorePlay, it will be a very daunting communication challenge. I mean, this could really be very difficult, and should not be underestimated.
But I still believe we should focus on 'making cores more valuable' — only when cores truly become practical and useful can we really succeed with the technology being developed. And JAM is helping us achieve this goal.
So JAM is a very key tool. The question is, how do we convey this message to the outside world: 'Hey, look, these cores can now handle a whole new set of tasks, and can also be expanded to more scenarios. Come and try it!' How do we get this message out? This is indeed very difficult.
I think Polkadot has made progress in terms of communication, but most are still at the level of 'communication' itself. And I have indeed heard similar feedback from many people.
It's like... well, our performance on platforms like Twitter has indeed improved a bit compared to before, but this communication is still more directed towards the ecosystem internally, unifying the perspectives of various parties within the ecosystem, rather than conveying the real information we want to communicate to the outside world to attract more attention and awareness. So I think this is actually two very tricky issues, and I currently don't have a clear answer.
I don't know... but I do feel that in the crypto industry, tokens play a very strong role in 'spreading signals'. So we also have to understand this in order to succeed in the goals we want to achieve, while also understanding how to utilize it. But we can't let it lead us, becoming 'just to issue for the sake of issuing'. So my answer is still — I don't know right now.
At present, JAM is simply a technical upgrade to Polkadot, that's all. This is the current position of the technical Fellowship. But like all cutting-edge things in this industry, everything may change in the future if a better path is identified.
Alice and Bob: During this period, we should let as many people as possible know about JAM and its potential.
Gavin: Yes, I think there are actually quite a few people who have 'heard of' JAM now, but there is also a certain degree of misunderstanding. People know the name, but do not realize that this is actually something they should be trying and practicing — I think this is the bigger issue.
This is a very significant paradigm shift. If your past habit was to define the type of chain as 'this is a new EVM chain' or to say 'it uses a different consensus mechanism', then you might not be accustomed to the completely new narrative of JAM, which does not belong to these old classifications; it is a completely different paradigm.
In any case, since we are discussing in the context of the technical Fellowship today, I don't want to let the topic drift too far.