The title is dot dowoism when jamming. Jam represents a significant step forward for blockchain technology but also obviously for Polka Dot, whose governance the DAO has remarked an intention to upgrade to. And what does Dow look like in the JAM era? First thing to say is I'm not talking about me or any of the organizations with which I'm affiliated doing any kind of issuance or sale. I want to make that clear that's not happening. And also what I'm saying now is in part conjecture, in part technical opinion, and a little bit of it is a suggestion, but just a suggestion. Can talk about the suggestion later.
So, my terminology has changed over the years. I used to say polka dot governance, seemed to make sense at the time, but in reality, I think there's too many things that share the nomenclator and don't really have dramatically different meanings. I think that can lead to confusion. In fact, I know it has led to confusion. So with that in mind, I'm going to switch the terminology that I use. Hopefully this won't be utterly foreign. When I say what I used to say is the polka dot governance, what I mean is the dot DAO. It's a DAO and it's controlled by the aggregate effect of DOT holders. So to me, it makes a lot more sense than polka dot governance. And when we talk about polka dot as a product, certainly the product that it was initially envisioned as being, I'm going to say that that's power chains. I wouldn't want it to be tied to simply the initial envisioned use case.
Now, JAM, what is JAM? You might look at JAM as a sort of simple technical upgrade, but it really isn't. It does something quite different. So, JAM, let's rewind a little bit. JAM is a collective computer. I used to say world computer like 10, 12 years ago. The implication being that it was a singleton, a global singleton, one of them for the whole world. Though the intention wasn't there to say that there can't be any others. I think there was some mistaken reading into that phrase. And I think now the preferred terminology would be collective computer. It comes about through the collective actions of many for the collective utility of many. And if we call it a collective computer, it kind of makes some sense because we already understand what a personal computer is. It's a computer for use by a single person, and an industrial computer is for use in industry by a company. So it sits quite nicely alongside these two other definitions of computer. And in reality, it's quite similar to these other types of computer. It runs software. It boots up as we saw with JAM. It can even run literally the same kind of software. The tooling looks very familiar. The main difference with a collective computer is that it's autonomous. It's not owned by anyone. So, generally speaking, because it's autonomous, it can be used by anyone or anything. Could be software that uses it. Could be a bot. Could be AI. It can be used anywhere at any time. It's ubiquitous. And it can also be used by very many people all at the same time. In Jam's case, not in every collective computer's case.
Now, early computers, if you rewind back into the 1980s, which I am actually old enough to have fond memories of, computers weren't as complicated as they are these days. They tended to have not that much going on inside comparatively. They tended to have just a CPU, which is the thing that does the processing, all the sums, the calculations, and some RAM, which is random access memory. It's basically the things that allow it to remember what it was doing, what calculations it had made, where it was in its calculations. Well, it turns out JAM's not very far off in terms of how it's architected and what it provides. It's not very far off if you squint your eyes and think conceptually from these early computers. It also has two kinds of resources, two resources really. It has the things that do the calculations, the cores, right? CPU cores. And also the memory that allows it to remember between calculations. CPUs and the RAM basically. You can also think of it a little bit as time and space. Processing happens over time. Storage happens in space. In JAM, I'm calling the space the footprint and the CPU things, the cores. If we apportion a core up into periods of time where you're allowed to use it, we call that core time. We already use this terminology in Polka Dot. Jam uses it as well. It's the same thing basically. We don't have the footprint in Polka Dot though. That's a new thing.
Now every validator, all of these operators, the ones that are contributing and manifesting this big JAM collective computer, all of them need to check each other's workings. It's not a case of everyone must check everyone else's workings like it is with certain other blockchains, but still they do need to be able to check each other's workings. And therefore, they need to be running sufficiently fast, substantial, powerful hardware in order to do that. They can't do that. Well, then that means jam is broken. And it turns out for a few reasons that roughly the sweet spot in jam operator hardware is this particular CPU and the memory probably go up and down a bit, but given that it's quite expensive and given that we want jam to be a sufficient level of functionality to be able to run polka dot and power chains and all the rest of it, probably this is about right as well, about 48 gigs. And if you have your operators with this hardware, that means that the manifested JAM collective computer has that amount of footprint and that number of cores. Jeez. Now these are hard resource limitations. If JAM tries to do more, you can't do more than 341 cores. The protocol doesn't allow it. And the protocol, as it turns out, also limits how big JAM software can get, like how much RAM it can take up. It needs to do this otherwise the computers that need to check each other's working might go too slow and then work might get through without being checked and that would break jam's security guarantees.
So, how do we manage if we have a system with users we don't trust and finite resources? Permissionless system, finite resources. How do we solve this? Well, turns out computer science has an answer for this. We have things called access tokens. Access tokens have basically imaginary tokens that give you access to a particular imaginary resource. If you are a piece of software and you hold this token, that means that you are allowed to use that resource. And if the token gets removed from you or you pass it on, then you no longer have access to that resource. And this allows in principle lots of different pieces of software to share a machine that has finite resources, share those resources without breaking guarantees over how much resource will be used. In our case, as I said, we have two basic kinds of resources. We have cores and we have footprint memory. Roughly speaking, we have about 20 million kilobytes of footprint or memory in JAM and we have about 341 cores exactly. There's also a couple of other tokens that are privilege tokens. These are special tokens that are like administrative tokens. They can again only be owned by a particular piece of software and the software can pass those around to another piece of software. But they can only be owned by one at once. That again is built into the protocol. It just turned out to be simpler to do it that way. So, we've got a few different types of tokens that convey software certain rights within the JAM machine, the JAM collective computer.
Now we get to the interesting bit. The DAO has about two years ago now signaled intention to upgrade to JAM once Polka Dot's core developers reckon it's ready. Well, here's the thing. Jam doesn't there is no network for dotdo to move on to. Polka dot to move on to that network that jam network doesn't exist. It would have to launch that network. And if it launches the network, well by default, the DAO as the sort of ruling entity of polka dot necessarily holds these access tokens. These tokens that let software in jam access the jam's resources. That's inescapable. So what does it mean? It means two things. Firstly, there's an upside. The DAO controls all of these resources. It's a good thing for DOT DAO. There's a downside as well, and that means that it's up to DOT DAO because it's the one that launches the network and holds the administrative tokens. It's up to DOT DAO to actually select and incentivize the operators. They don't just come of their own accord, the validators if you like. Now, this already happens on Polka Dot. Polka dot already selects and incentivizes its validators. It's nothing new. And Polka Dot already has cores which it sells time on. But there is one new thing here which is Polka Dot doesn't have footprint.
Now jam services do things that power chains cannot do. They can host virtual machines and these virtual machines can have particular properties that cannot be matched with power chains. Not all of them anyway. The first property is continuous and indefinite execution. You can put an infinite loop into one of these virtual machines and it won't break jam. It'll just execute it like it would execute on a regular machine. 10 print hello world, 20 go to 10. That can execute. It can kind of execute in a smart contract as well, but it will eventually stop. Eventually, the block will run out of gas and the smart contract will have to be terminated. In JAM, at least in one of the VMs, that doesn't happen. It's high performance and this is something that can ultimately be utilized within power chains as well. And JAM has huge network parallelization. In principle, the work of these 341 virtual CPUs, virtual cores, is spread out amongst a thousand different machines all over the world. We're not talking about just using a couple of extra CPU cores here and there. We're talking about massive global parallelization. But here's the really clever thing that JAM VMs can do that parachains cannot match: synchronous composition alongside all of these things.
What does synchronous composition mean? For this, I'm going to have to use an analogy. Suppose you imagine a regular smart contract blockchain as a sort of office worker, 1970s office worker rocking up into their office. A regular smart contract blockchain turns out that you have lots of office workers for all the different smart contracts on it, but there's only one office, so they have to take turns in the office. And because they're taking turns, they kind of carry all of their working with them in a sort of suitcase, a briefcase. When they get in the office, they have to unpack it all, do the work, and then pack everything back up again so that it's clean for the next office worker. Furthermore, they're time limited to just like 5 minutes. And after that, even if they haven't finished, they still have to pack up and get out because the building is closing. This is basically a regular smart contract system. Now the one good thing is that they are allowed to invite other office workers into their office to chat. They can't both work together, but they can chat. This allows rich communication between office workers. Very immediate, very rich. Now with power chains, Polka Dot took this analogy and said, okay, rather than just having one office, we're going to have a few dozen offices and office workers. They're tied to one particular office. They can do all that other stuff, but only in the office they're tied to. If two offices want to communicate, they have to send a memo. That's called XCMP in Polka Dot terms. And it takes some time. It's a lot worse than just chatting there and then with the coworker.
Now what JAM brings to this is it says there's lots of offices still, maybe a few hundred rather than just several dozen. But it means that firstly the workers don't need to bring their briefcase around with them. Their desk just sort of teleports into whatever office they're in from the last one. They don't have to pack and unpack. It's like they've got a continuous presence regardless of what office they're working in at the time. There's no periodic vacating. The office building doesn't need to close. The workers are a lot faster because we use a much more performant system, and at least for smart contracts, it's also easier to hire the office workers I suppose in that it's easier to code these things because we have gas accounting. Finally, and what's most important, is that the office workers are not tied to a particular office. They can move freely around, and this means that any office worker can be in an office with any other office worker at any time that it makes sense. The offices have a limited amount of workers that can be in, but you're not restricted on how you organize your office workers like you are with other L2 systems such as power chains. This is crucial for building a very highly scalable smart contract system.
Okay, so we have this amazing new utility, this new kind of thing, new resource. How does it benefit dot? Well, dot now by default starts with all these resources. For cores, nothing really changes. It can still sell core time. It could sell the core itself, but that's a pretty hardcore thing to do. It's like really selling a very important piece of functionality and it only has 341 of them to sell. So more likely, especially as cores are not stateful, it sells time on them, rents them out for little bits at a time. But it also has this other thing, footprint. The cores are not useful to rent unless you're a service, and you can't be a service without footprint. So here is my illustration of this situation. Jam with Polka Dot will lead to almost certainly heavily underutilized JAM because Polka Dot, the power chains model, does not utilize JAM well. It utilizes JAM somewhat and it has existing functionality that makes a lot of sense to ensure is in, but it's not, I suspect by definition it will not utilize jam.
So if DOT DAO wants JAM to be utilized well, and we presume it does because at the end of the day the DAO's income stream is the sale of core time on JAM, the rental of these cores, one type of resource. If it wants that to be as valuable as possible, as useful as possible, then it needs to somehow get other types of services than power chains out onto Jam. Services that utilize this magic that Jam is able to provide. There's a few ways that I can think of doing this. There might be others. Not claiming this list to be exhaustive. Loans, right? The DAO could loan some of this footprint out into the wild into other services. Could decide what projects it wants to loan them to, loan them, reclaim them. Jam has that kind of reclamation functionality if the service agrees to it. Basically, a service can nominate another service to have administrative privileges over it. It's not ideal because if another service has control over you and that service has a security bug, then you have a security bug as well. Not ideal, but in principle, this could happen. Leases, sort of the same as loans but with some payment attached. The slight issue with leases is pricing and supply are going to be opaque and arbitrary because it's a DAO that's ultimately in control. But more importantly, the technical implementation of reclaiming footprint from a service is quite difficult. You see the problem is you can't just take the tokens back if they're in use. Footprint is an access right. It gives you the right to use up RAM. If you just take the tokens back, the RAM's still used. And if other services come and use the RAM as well, then you've got too much footprint and you're breaking jam. So you always have to make sure that the RAM has been cleared before the tokens move. That means you have to faff around trying to work out where all the data is stored and issue instructions to remove it. It's possible, but it's costly and quite faffy. Not the sort of thing that you want to be doing very often, and it would lead to much more costly utilization than otherwise.
Gifts and rewards, they could just hand out some footprint on the basis of continued excellence or whatever. I don't know. Again, it would have to find those teams, those service authors. I'm not sure how easy this would be. Finally, it could actually just put the footprint on the market. It could also put the cores on the market, but as I said, they don't make so much sense. The key difference between cores and footprint is that footprint is stateful. With a core, you can basically split it up over time and sell just one little bit of it, one little window of time. Once that window is done, there's no cleanup required. It's stateless. With footprint, you can also sell the ability to store some data for a period. Periods probably have to be longer since services are generally long-lived. But the problem is that you can't get the token back without clearing the memory. If there's a lot of memory, it's going to take a while to clear. It's also a lot of effort. Probably also need some transaction fees, certainly some cores. Everything becomes a lot harder. So if one of the types of tokens is to make it out, it makes a lot more sense in my mind for it to be footprint.
So what am I suggesting? We have these. Dotdo will presumably launch jam and in doing so by default come into ownership of these jam access tokens. Cores probably I would propose jam keeps and sells time on much like it's doing at the moment for power chains. But footprint, I would suggest, it sets aside 50% of them and the other 50% it slowly releases into public ownership. Good. That's the talk. I'm now going to do a fireside chat with Erin. Thanks for your attention.
