This is the gray paper, the JAM gray paper. It's a formal specification in the same rough format as the yellow paper, the thing that I wrote back in 2014. That's the formal specification of Ethereum. I mean, it's been altered by a bunch of people that are not me over the years, but the original document, the original formal spec was fine.
Like the yellow paper included the EVM definition, this includes the PVM definition. This is like the blueprint for a building. It's not built yet, but this tells you everything you need to know to be able to build that building. In order to make sure that this doesn't describe something that's impossible to build, there is a team, there's actually more than one team at the moment, who are building it and making sure that it's reasonable, it's practical. But the idea is that this blueprint should be reproducible. Other people should be able to build it just from the blueprint. So we want this blueprint to be correct and comprehensive so that we can give this to, you know, the best theoreticians in the world so they can check it and make sure it's good. Make sure it's structurally sound and check that if it rains the roof doesn't cave in and if it blows too much wind the wall doesn't fall down. This is where publication comes from because by publishing it, we can allow theorists to start looking at it and picking out problems and hopefully solving those problems as well. But, you know, and working out which bits might be better optimized. You know, this has only had a few different sets of eyes on it. It needs more sets of eyes on it. So, we want to optimize it further.
We want to improve it. And already, you know, there are ways that I'm thinking that are already sort of going over how it might be improved. And one particular thing that I want to do is that we're sort of coming to an endgame design for, I'm going to be working into this over the next few days. So it's probably going to evolve. The Ethereum yellow paper evolved in the same way after I published the yellow paper. I think in around April 2014, probably I think today 10 years ago actually. After I published it, it changed. It changed over six, seven, eight months as auditors looked at it. They picked out problems and they made suggestions for how to improve it and so forth. And we found by implementing it, things might change in some ways. I remember logs and receipts changed quite a bit over this period of time.
So of course most people that come to Polkadot know it by parachains. Parachains was the product. It was the original proposition of Polkadot. But in developing Polkadot and making it work, we ended up creating something far more powerful, which was this system for doing a lot of computation and doing it securely in consensus. It's not being fully utilized in many respects. One of those respects was this idea of having one parachain per core. Core is like the term we use for basically a sort of discrete portion of the computational resources that Polkadot provides. And really the point of JAM is to be able to use this invention for things other than what Polkadot's original product offering was. This idea of one parachain per core means that parachains that don't really use that much resources end up using or taking up an awful lot of Polkadot's time when that could really be better used elsewhere, perhaps in some applications that need more but wouldn't pay as much, or perhaps in other parachains that want to go twice as fast and not use twice as much of the Polkadot resources. Because this was helped a lot with agile core time, which is this upgrade that's being, I think it's rolled out now, it's being rolled out if it's not already rolled out to Kusama and it's on its way to being rolled out to Polkadot. And this allows for the possibility of cores to be used other than in a one parachain per core, one core per parachain manner.
Unfortunately, it doesn't go as far as I would like. In particular, it doesn't allow cores to do the sorts of tasks that I think will be very interesting to allow them to do. At the moment the model of a core is still very much based around what it is that a parachain needs. Whereas we can think already of other things that would still be able to use this underlying resource that Polkadot's generating, secure resilient computation, but to do so in a slightly different model of usage. And JAM is created to be a reasonably unopinionated, general way of providing a model for using this resource.
I mean I actually saw a film only two or three days ago, The Imitation Game. It's a film about Alan Turing and the creation of this, you know, one of the earliest computers, one of the earliest electric powered ones. Machines up until this point had tended to be built for a particular purpose. And the ability to reuse a machine for many different applications would have been considered a luxury that wasn't worth having. But the ability to reuse the same machinery in different ways allows for levels of innovation that you just can't do if you have to rebuild and reinvent and redesign the machine, this underlying hardware, capital, metal and wires and so forth, every time you think of a new way to use something. And so this idea of a general purpose machine was something that Turing was very excited about. There's even a line in the film about someone sort of jibing with him saying, 'Is this really just a way of you getting the government to fund building your general machine, your universal computer?' And that's really what we mean by abstraction. We mean, you know, taking things down from the level of direct usage, the level of direct application to something that's more general that can be used for things other than what we initially might imagine. And this is what allows for innovation and it's, you know, we see it everywhere in computer science. Abstraction is the first thing they teach on at least my course. Thinking in general terms. Providing other people or indeed your future self with the tools that allow you to innovate without the need to reinvent the wheel, rewrite everything from scratch. So finding the right abstraction level is crucial. If it's too low, if you're designing everything to be absolutely as general as possible, then you end up, you know, getting down to the point where you're still having to rewrite everything every time because so little work is done, so little tooling is provided already. Whereas if you set it too high, then it allows you to do a very small number of particular applications well, but once you move beyond this initial design concept, you'll find that it's unapplicable to what you want to do and then you have to start from scratch. So there's a sweet spot where you're abstracting just the right amount to make what you've done very applicable to a lot of different things including one would hope many things that you've yet to imagine.
In some way I think we're going a little bit backwards actually. So we started with, and I mean this has to all be caveatted with I am not someone who reads blockchain news daily. I'm not someone who keeps up with all the latest trends or the latest thought leaders. Stuff gets to me but usually gets to me through other people. Anyway, the point is I spend most of my time thinking and coding and less of my time reading. Now back when Bitcoin was the thing in like 2012, 2013, the assumption was that the abstraction level was pretty reasonable, right? There was you could send Bitcoin, and there was this scripting language that let you write some kind of interesting, I mean interesting, not that interesting in the grand scheme of things, but you know, do some slightly different things with it. You could work out how to make funds that unlocked on certain conditions. You could work out how to do multi-sig schemes where many different people can control a particular amount of funds and so on. Then Ethereum came along and it was like, right, we're going to drop the abstraction level down a little bit. We're going to say, you know, or at least that was the proposition to drop the abstraction level down a little bit. Say well we're going to generalize. Now in reality you could question that. You could say well it didn't really drop the abstraction level down because it added much more to it in many respects. Ethereum added a lot of features to Bitcoin. It certainly added a lot more instructions in its scripting language, EVM. And it added this concept of gas. It added the concept of storage. And yet it still retained what Bitcoin essentially had, which was balances. So in reality it kind of added quite a lot. It's questionable whether it really dropped. I mean I would say it didn't. In fact I would go quite far and say no it didn't. It did generalize in that it allowed for more things to be done but it did so at the addition of facilities, at the increasing of complexity. Now Substrate I would say on the other hand actually did abstract right. It said right, the blockchain won't do anything on its own. It will just execute WebAssembly, like there is a WebAssembly layer but it didn't come with any opinion of its own. You could implement Bitcoin on it or you could implement Ethereum on it or you could implement basically anything on it. If you wanted a simple sequential blockchain then Substrate could be used broadly speaking for whatever it is that you wanted to do. And we're still seeing new Substrate chains pop up that do legitimately different things, things beyond what we would have imagined.
Now still nonetheless EVM, Ethereum, reasonably general purpose even if it's questionable whether it was really an abstraction from Bitcoin. Now, where the direction that we're really going in now, at least within the Ethereum community, is to really move to make the EVM more of a zero knowledge proof aggregator. So in reality, you're using an increasing amount of these fixed function elements called precompiles in Ethereum language and you're really only using the EVM to script these precompiles. You're not really doing much work on the EVM itself. In this respect, it's making the main Ethereum EVM chain more of a domain specific chain. It's reducing the abstraction. It's making it more specific to this application by adding these precompiles and making most of the usage be these precompiles. And I mean that's not quite the case at the moment, but the suggested future direction, the implied future direction is to reduce non-zero knowledge proof work, verification work done on this main chain and instead move all of the work, all of the interesting business logic out onto other chains that then get verified. In doing this, what they're kind of, you could argue, doing is recreating the Polkadot relay chain, which is very domain specific, specifically for essentially rollups, right? It provides its own rollup mechanism where it's rolling up the computations done in each of the parachains. That's all very well but it's definitely moving in the direction of domain specificity and not abstraction. It's moving if you like up in the abstraction space closer to this high level application rather than lowering and becoming more flexible and more general. Whereas with JAM, well, we're already at this Polkadot relay chain situation. And what we're doing is we're actually moving down the abstraction spectrum and we are increasing the generality, reducing the opinionation. And I think this is something that I'm excited about. This is something that I think leads to much more interesting possibilities and I'm also quite, I mean you know at the end of the day there are opinions in JAM and many of them are, some of them have come from me, many of them don't come from me, many of them just come from how Polkadot relay chain and its security apparatus has been designed and architected by the research team and various developers. And that's fine. I think over time we will see that some of these design decisions could be optimized and we'll see alterations in the JAM protocol, but I think for now it opens up enough doors that it's worth pushing forward with.
It began quite a long time ago. It began with a forum post by Basti, one of the main developers of Polkadot. It was a throwaway forum post of his, you know, it was like a one-liner. And it was in response to I think the initial PolkaVM announcement. It was maybe a year or so ago. And he said well maybe we can move towards, maybe it was actually core time. It was either the agile core time or the PolkaVM. In any case I think it was around a year ago. And he said maybe we could even put some smart contracts directly on the cores rather than running them through parachains that sit on the cores. Maybe we can just run smart contracts right there in the core. This would be a lot faster. You can only do this if you have metering in the core which we don't have with WebAssembly. You could also only do it if you could kind of rent a core out a little bit at a time which we didn't have back then but we have now with agile core time. So this sort of combination of having PolkaVM as a metered but still very efficient means of running machine code, of running software basically, in addition to having agile core time, essentially sort of lets you buy this secure resilient computation and run software, whatever software that you want on it, in isolation, not necessarily software that has to move a blockchain forward. Now this is interesting but the problem with it, well there are a number of problems with it. The biggest one was this concept called synchronous composability. Synchronous composability is the idea that two different logical pieces of a system can interact with each other with immediacy, right? So, it's like kind of having a phone call versus sending an email, right? An email or even a letter, you know, like a pen and paper letter. Sending a letter takes days to arrive. And you've no real guarantee that it, I mean, most of the time they arrive eventually, but you know what Royal Mail is like? It's like maybe it takes a day, maybe it takes 3 days, 4 days, maybe it gets lost somewhere and then eventually turns up a week later. There isn't really this level of certainty and it's a lot harder to collaborate with someone if you're forced to do it over postage mail, right? You can do it. You can collaborate a bit faster over email, but the fastest way to collaborate is like in person or over the phone, right? Video call. This is much much much faster if you want to collaborate with someone than faffing around writing emails or letters because you just have that instant feedback. And that's why synchronous composability or basically allowing these components to interact with immediacy rather than firing off a message, sleeping for a while, maybe a block, two blocks, 10 blocks, 20 blocks, 100 blocks, then waking up when the reply arrives. This isn't the way that you're going to be able to build really intricate machines with different components if each component has to wait this indefinite amount of time to interact with another component. And this is the situation that we have at the moment with parachains, right? They can interact with each other, but it's much much much slower and more expensive than when they interact inside of themselves. When they're interacting inside of themselves, we call this synchronous composability. If they host many components, like for example Moonbeam with its smart contracts, those smart contracts can interact synchronously, right? They can basically send and receive messages as though no time has passed. But as soon as Moonbeam wants to interact with some other parachain or maybe across a bridge onto like Ethereum or Kusama or whatever, then time will pass. They basically, if they wait for a response, they have to go to sleep, right? They have to sleep on it. And it could take a really long time for the response to come. This makes doing certain applications impossible and it makes doing other applications a pain in the ass. Now there are ways of programming that help this. But those ways of programming are not really applicable to this environment for a bunch of technical reasons that I'm not going to get into. So synchronous composability is really really helpful. But the problem is if everything is synchronously composable then it means you have to have everything all in the same place all of the time and there's a limit to this. It's kind of like, you know, dinosaurs, is it dinosaurs? Are they cold-blooded? But it's basically the limit to a cold-blooded creature. It's like they can grow and grow and grow but eventually you've got this ratio, right? It's a ratio between the volume of something and its surface area. And as that ratio gets beyond a certain point, that system can't exist anymore. It doesn't work because basically it takes too long for stuff to get from the surface down into the middle and for stuff that maybe is in one place to be able to circulate around and get to some other places. It ends up having basically hot bits and cold bits and the whole biological metastasis breaks down. It stops being a coherent living entity. And it's basically another reason why like for example the biological cell just can't grow to the size of a person. It has to be many different cells all working kind of in concert but independently as well. Yeah. So you see this in biology, you'll see it in all kind of information based systems which basically means all systems. They can only grow to a certain size and expect coherency and synchronicity. Which means if you want to grow, if you want to scale a system beyond this limit, and it's not to say we've necessarily hit the limit yet, but if you want to scale beyond this limit, you have to break the system down. Now, that's all very well, and this is exactly what they're doing with Polkadot parachains, and it's what Ethereum's sort of doing with having multiple ZK rollup things. And you'll see a few other examples of this where the system is being broken down into different discrete subsystems and those subsystems work nice and quickly synchronously coherently in and of themselves but then it's a pain in the ass if you want to go between subsystems. So what is really helpful is if we accept that a system needs to be broken down but rather than breaking it down into what I'm calling now persistent partitions or fragments. So which is to say like a parachain is persistent. The stuff that lives on a parachain lives on the parachain. It lived on the parachain a day ago. It's living on the parachain now and it's going to live on the parachain a day in the future. It's a persistent fragmentation of the overall state. The smart contracts that exist on a parachain, they can't freely move to other parachains, right? They sit on that parachain. They stay there. Now, you know, there's not many exceptions to that. Now there may be in the future there can be some very heavily small-printed exceptions to that but basically that's how persistent fragmentation works and that's what to date has been how people have thought about the approach to scaling. Persistent fragmentation, and as I said this comes with drawbacks. A system broadly speaking is fragmented but it's fragmented at the level of application boundaries or user boundaries or geographical boundaries. There are usually boundaries to a system. It's usually not the case that all components of a system want to interact with all of the components exactly the same amount of time. Right? Usually you can say well these bits want to interact and those bits want to interact but they don't need to interact too much between themselves. One could imagine that for example if one had the global transacting system, payments in China mostly go between Chinese residents and Chinese companies and payments in London mostly go between London residents and London companies. And occasionally a Chinese tourist spends some money in London and there has to be this thing. And occasionally, you know, a British tourist goes off to Shanghai and spends some money there. But most of the time, there are these boundaries. But what we don't really want to have to get into is predetermining where these boundaries lie. What would be much better is if we had agile partitioning, the ability to partition and change partitions over time. The less decisions we make up front, the less chance there are that we made a bad decision and our system is really suboptimal. And so we end up with this desire to be able to mix and match, to choose our partitions but to do so every instant of time right now. Now we can't do it literally every nanosecond because that again is too much shunting stuff around and working out which bit should go where and logistics basically. So we have to be practical and pragmatic about it but it's not unreasonable to say well look every block, every six seconds let's try and reshuffle our partitions according to which bits of our overall system need to interact with each other. Yeah. Because maybe sometimes it's like these bits need to interact and these bits need to interact. But other times those bits and these bits need to interact and so it's, and if we end up in a position where a lot of the time these three groups need to interact it could be quite helpful to sort of pair them up right, every and then just interleave so every third block a different pair of these three subgroups are interacting and this allows us to use much more resources at the cost of adding a little bit of latency, right? If it so happens that someone from here wants to interact with someone from here, but it's not their turn, they have to wait until it's their turn. So, they might have to wait another 6 seconds. But that's generally not such a terrible thing compared to persistent fragmentation where they always have to wait a minute plus or a lack of scale where they just can't fit in the same system and half of these guys and half of those guys just aren't allowed to interact. And this agile partitioning requires the ability to mix and match different logical components, putting them in the same core. Yeah. So with parachains you had just one logical component, the parachain. I mean it could have subcomponents but they were always in the same logical component, the parachain. And you fit exactly one parachain, exactly one logical component to one core. With JAM, and this is one of the key differences with JAM, you can fit many different logical components and put them in the same core. And this allows you to do this agile partitioning.
There are a few other important elements to JAM. One of the other ones is a two-part computation. So, JAM allows for the computation to be broken down or forces in fact the computation to be broken down into two discrete sections. One of them is called the refinement section, the other is called the accumulation section. Now basically the refinement section is you can imagine this is a bit like a flower. So flowers have petals, right? So think of something, I don't know, like a chrysanthemum that has all of like hundreds of petals? Yeah. And they're all like quite thin, right? Yeah. So think of a chrysanthemum. So the data, it's got like 300, 400 leaves. So the data comes in at the end of the leaf right and it makes its way through the petal and as it makes its way through the petal, lots of computation can happen. Petals are like computers, right? They take this data and there's lots of data can come in at the end of the leaf and lots of computation happens and then eventually as it works its way down the petal, it gets into the middle of the flower, right? The bit where if you can pull the petal out of, it's the bit where it was joining in the flower, which I'm going to call the center of the flower, right? The data gets into that center but the center is very very small. So only a little bit of data can go in compared to the amount of data that was coming in at the edge of the petal. But the data when it gets into the center can mix with all of the other data coming from all of the other petals. Up until then it could only, you know, the data just had itself within that petal to be interacting with. So when it gets into the middle, it can interact with all of the other petals' data. And then the middle is what keeps track of where things are at. Right. Now that's your basic model of JAM. JAM, Join-Accumulate Machine, is basically this accumulation stage. It's a machine that accumulates. Core JAM, Collect, Refine, Join, Accumulate, is the whole sort of protocol. So it's this idea that you collect data like petals sort of collect rain or whatever coming from the outside and they refine it. So this data goes through the petal towards the center of the flower, refining this data and distilling it into some concentrated meaning. Right? And then in the middle of the flower, all of this distilled data is collected together and then it's accumulated. It's all intermingled and whatever logic needs to happen to combine it into the next flower, you know, the next stage of this flower. Well, that's the JAM chain. That's the Join-Accumulate Machine. So it's joining all of this incoming petal data together and accumulating it which basically means doing the final processing and taking the repercussions and registering it in the machine.
So formal specification basically means a description of the protocol that does not have any significant opinionation in it. So it's sort of like a very pure description of the protocol. A pure description of the protocol can't really be done in anything other than a very pure language. And so you wouldn't really want to do it in English. You wouldn't want to do it in a machine language. You'd want to do it in a very conceptual language. And you know, as it turns out, maths is a pretty unopinionated language to describe how a protocol should work because it specifies only correctness rather than being forced to specify how something should be achieved, right? Maths doesn't really allow you to specify how something can be achieved. I mean, you can dance around it, but it's not something that you can, because there is no general maths computer, right? Maths is really a language for specifying what is the correct outcome. Now, of course, if you only describe what is the correct outcome, you could end up making something that is unimplementable. For example, you say the correct outcome of the system is the piece of data which when hashed cryptographically results in all zeros. Right? Now that's perfectly specifiable in maths. Nothing problematic about that at all. But it's impossible to implement as far as we know. Right? So care has to be taken that when you're specifying correct behavior, it's possible to implement a practical machine that does do that. And normally you have to tie your formal specification to a real implementation so that you can see both you have the correct behavior on the one hand and you have a demonstration that it's practically possible on the other hand. But if you skip the thing that says what correct behavior is, then you end up with all of these elements of making it work practically on some particular platform, whether it's, you know, x86 machine code or Python or whatever, on some platform, not specifying simply what correct behavior is. You can say, well, correct behavior is what this thing does, but then what that thing does may have very particular platform-specific considerations because it needs to actually make it work. When you have an implementation you're specifying how something should be done not what should be done and there is a difference between this. To take a simple example, a sort of analogy, you might see someone cook a meal. Right? Now, if you see someone cook a meal a hundred times, you're probably going to work out which bits that they do are the important bits and which bits that they're doing are not important because that changes between the different examples. But if you have simply one example to go off, if someone, I don't know, and maybe that example is you're not able to watch them in person but it's actually a film of them doing it and therefore you've got the opinionation of the filmmaker in addition to the chef. Then you are stuck with not knowing which bits are important and which bits are not important. Yeah. And you end up with, well, you can end up with a cargo cult forming. Basically, someone reproducing the unimportant bits and missing some of the important bits. It becomes dogmatic indeed. Because you're not specifying what correct behavior is. You're giving an example of something that exhibits correct behavior, one would hope. But from that example, it's not always so easy to determine which bits are correct behavior and which bits are incidental behavior. And now, of course, you can say, well, this bit is incidental, this bit is correct, and so on. And of course you can try and use an implementation language to express correctness alongside a lot of comments and commentary and annotation. But ultimately you're still going to have quite a lot of opinionation, accidental opinionation, unintended opinionation, unknown opinionation, it's still going to be in there. I mean it always is when it's a person writing it. It always is. But when you use maths, it forces you to be, my opinion is it forces you to be a lot more, it makes it a lot harder to be opinionated because maths really really makes it hard to express anything other than correctness. It's still possible but it's really hard. And especially if you force yourself to put it not merely in maths but in the simplest most concise form of maths. So you really limit how much maths you have to play with, how many symbols you want to use, how many formulas you're going to put it in. Again, this reduces the possibility of opinionation because you're forcing yourself to adhere to this metric, to respect this metric of conciseness, essentially of reducing the amount of information in what it is that you're presenting. You can't do the same thing when it's implementation because implementation languages, their form of conciseness, they're made for expressing not correctness but rather how to do something. If I have a small program in C, probably if I try to compress a program in C it's probably going to use lots of pointer arithmetic because C it turns out is really expressive for things like pointer arithmetic. If I have a very short program in I don't know Intel Pentium MMX machine code that does a lot of work then probably it's going to have lots of the CISC instructions that were introduced in the MMX because this allowed you to do more stuff in a shorter amount of space. Again, in both cases, it's about the designer of the language and their ideals that come through when you're pushing for a very very short expression. If you force yourself into maths, there wasn't really a designer of maths, right? Set theory is really quite a minimal construct for expressing correctness, expressing axioms, right? Axiomatic systems. And so by forcing yourself to be as concise as possible, you are in some way optimizing for the purity and non-opinionatedness of your work.
So yeah, I mean the vision at this point is to stop the relay chain and start the JAM chain and migrate everything over from the relay chain into the JAM chain because the thing is the parachains, what you can look at the relay chain doing is just having an application. It's an application, right? It's the parachains application. Well, that application, that service, parachain service, JAM can host services. And the cool thing is that JAM can host lots of different services. And we can write a service under JAM that is the parachains service. So we can actually write what it is that Polkadot is doing, the relay chain is doing right now as just a service in JAM and then we can add other services to JAM later that use what JAM provides in different ways. So the thing is the relay chain needs to combine, like you can look at, if you imagine each at the moment each of the, the relay chain looks also a bit like a flower, right? Each of the petals process a parachain, okay? They make sure the parachain is, like one block of it has been executed correctly. And then you say well what's the middle doing then? What's the center of the flower doing? Well actually what it's doing is it's, aside from recording where the parachain is at, like the parachain's current state. It's also relaying messages between the parachains, hence the relay chain, right? It's also providing this sort of data conduit and it's also giving messages back again. It's telling the chain which messages it should also be receiving. So it's able to both receive messages from the parachain and tell the parachain which messages it should be looking at. So it does all of this stuff. That's basically what the center of the flower does. But the thing is that center of the flower is kind of hardcoded on the relay chain. I think in principle it would be possible to evolve the relay chain but I think it would be a sort of death by a thousand cuts because it would be a really a lot of evolution and every step in this evolution would be breaking and parachains would I think they would tear their hair out with like, you know, each of these breaking changes over and over again. So my feeling here is to, there's one other reason as well which is technical debt. There's quite a lot of technical debt on the relay chain now. So initial design decisions that turned out to be maybe not optimal and you've made changes but the thing is those changes are generally required to implement the thing that there is now in a not so great way because you had to take account of the fact something else was happening before. And that's really where we're at. We've done I don't know 5 years of coding. How long has it been? Started 2018. Yes. Six plus years of coding on Polkadot. Right. We have a pretty solid idea about how to make these kinds of systems work. And it's different. You didn't have quite the same understanding of how to design these systems at the beginning. And so it makes sense now with such a substantial change point I think to start afresh and start with a slightly different approach. It'll be work to do this tooling and to make it nice and super smooth, but it's a one-off thing. And at the end of the day if the migration takes 4 hours and it means that, you know, finality suspends for that period. It's not the end of the world. Parachains would still keep going. It's just that they wouldn't be finalized. So anyone who was doing anything of any significant value on the parachain would probably want to actually run fully synchronize the parachain or connect to a synchronized node that they trust for those four hours, right? And then after that it starts getting rejigged by the JAM chain and everything is good again. So yeah, I mean I think realistically that four hours is probably an overestimate. Realistically, it's probably the case that it could probably be migrated, you know, in like, I mean I, you know, I'm...
I'm going to pick a number out the air now, 15 minutes. But the point is that it's a one-off thing and it can be prepared for. It's a pill that you take once and when you've taken it, you've cleared yourself a huge amount of technical debt. There are a few other advantages, one of which is the ability to have a formal specification, which isn't something that we could do if we kept on the current track of using Substrate.
I can't make the decision to halt the relay chain and start the JAM chain and move everything over. This is a decision that should be taken by the community. And so one of the things that I'll be doing is putting out a proposal for a governance motion that basically doesn't say implement this and deploy it and we're done, but rather says this, as it's described, is a reasonable direction. And we, the Polkadot community, the DOT token holders, gathered DOT token holders whose plurality commands governance, we ratify this as the direction we want to go in with Polkadot.
And what does that mean concretely? Well, it means allowing the Polkadot Fellowship, or rather bestowing the Polkadot Fellowship with the responsibility to finalize this into a protocol. Bestowing on the Web3 Foundation the clarity that it needs to support and sponsor further development of this, in particular implementation teams. It means bestowing on the Fellowship the responsibility to create the service and the migration tooling, this parachain service and the migration tooling that will make Polkadot version one, or whatever the relay chain, compatible with JAM. And it means bestowing on the Fellowship the responsibility of halting the relay chain and starting the JAM chain, and basically looking after that migration when the time comes and dictating when that time is.
So basically it's a 'yep, we're up for JAM, and Fellowship, make it happen.' In part it's up to me to convince other people. In part, it's up to me and for that matter, other people that are working on this broad project to respond to needs and comments and maybe move it in the directions needed such that it makes most sense for its users.
