Protocol Berg v2: Gavin Wood - Beyond the Ledger: JAM and the Future of Scalable Decentr. Computing

Thank you. Thank you. Cheers. Thanks. Nice to be back in a different place though, eh?

Um, bit more full on. Um, right. I've uh I got like kind of three broad things to talk about. Um, and I'll try and do what I don't usually do, which is leave time at the end for questions. Uh, right.

Let's What do you want to show on it? Um, the screen, I guess. Mirror. All right. Good.

Um, so I'm going to jump straight in. Um if you don't know uh I've been actually my my talk last year at Protocolberg was uh discussing um the protocol that I'm working on JAM. Um and now we've done a lot more work on the protocol. We have some numbers and we have some further insights and I'm going to basically go over those numbers and insights and uh try and give you a demo of it towards the end. Um the first thing I want to cover is the security mechanism for JAM.

So, if you're not familiar um with JAM, it's a it's blockchain um and it's it's broad direction is to take a lot of the work that we did for Polka Dot and combine it with a lot of the um or with some of the elements of Ethereum, particularly um having a single coherent um object environment. And one of the things that we really uh nailed with polka dot was getting um a lot of computation through um that was very uh secure. So we basically scaled our base of security really nicely. Um now the um the sort of uh the product that we used this uh scaling mechanism for is probably a bit before its time but um the underlying tech was uh uh is um awesome and this underlying tech is what's being um leveraged with JAM and I want to just like give you an idea of how this underlying tech works because we've seen with uh scaling security um in in protocols we've seen a lot uh a lot of work, a lot of a lot of hype, a lot of visibility go into utilizing some of the uh you know the the ZK um uh tech that we've seen arrive over the last five or 10 years um snarks and stocks. And one thing that we've found uh doing our own empirical analysis of this technology is that it's shitty for scaling security.

Uh which is why we don't use it for that. We use it for other stuff but not scaling security. So JAM and for what it's worth polka dot security um mechanism is based on elves. This is a protocol that was devised at the web 3 foundation and um you probably understand parts of it quite easily because parts of it are kind of uh say take some inspiration from what Ethereum would call optimistic rollups. But the basic problem it's trying to solve is this um everyone computes or verifies everything approach to blockchain security to giving security to computation giving a um a guarantee that the computation that has been done is indeed that these are the correct results and of course that there won't be any um alteration in the inputs um also known as finality.

And the way that we uh scale security is perhaps not super surprising. We use divide and conquer. You know, something that's used all over the place in computer science. Um in this case, we take our set of validators, say a thousand of them, and we have um we split up the work that we want to ensure is being done correctly between These nodes, say three nodes per piece of work, and then each of these bits of work come with uh a bundle together with a bunch of uh uh information that proves or can prove statelessly that the work was done correctly. And probably this is already starting to sound kind of familiar.

And um once we agree that each of these bundles are uh definitely available to any um any additional validator that wants to check it. Um then we can agree that this work is ready to be checked and after checking ready to be finalized and this is what we call auditing. Now the um and the way that this protocol works, the sort of clever bit of it is how the auditing the get the the rules for when audits happen and who does them. Um these are very subtle rules um and they have to be designed uh very carefully so that it's not possible for some attacker to um get something past the auditing stage without an honest party at least one honest party uh being able to audit it um with a reasonable expectation that if they audit it and it turns out to be invalid that they broadcast it to the other honor. parties and we have you know various like the elves protocol comes with the main sort of paper comes with various um base assumptions in terms of honest parties and connectivity and all the rest of it that you would typically find in consensus protocols.

Um and the nice thing is that there is a uh the paper ultimately proves um that under these rules um the likelihood of a malicious party sort of getting away given these assumptions is approximately the same um as uh as if the whole network itself were checking these things these uh these reports. Um the one of the sort of ways one of the little tricks that the protocol uses is um announcing before validating and this particular trick is an important one and it's there in order to ensure that if a validator um gets dossed basically if they get prevented maybe there's a bug in the client and after uh and and if it is known that this uh validator can uh is going to do an audit. They will uh they could potentially be dossed, taken down, and maybe the audit is going to pass. Maybe the the the report is going to pass without being properly audited by an honest party. Or maybe they do audit it and they get taken down afterwards or immediately on auditing in order to prevent the negative judgment from making its way to other nodes.

Either way, we want to avoid this possibility. And so what we do is we require um auditors not only to self- select based on a verifiable random function but also to announce before they do anything else. And once they announce it's almost like a contract. Any other auditors that any other validators that see this announcement and don't later see a positive judgment. It sets up the default and the default is audit it make audits more likely for this package.

basically find other validators that will audit in the place of this missing report of this missing judgment for fear that um there's some sort of DOSS attack going on. And because this rule and a few other subtle rules um we can make a proof that this gives security um approximately in line with just having all validators audit everything. And this allows us to scale the security uh that we provide um for our work that happens on chain. Now if we compare this to the assumed alternative which is basically having some effective GPU supercluster whether it's located in one particular space or distributed around a bunch of different nodes. Um if we compare the actual uh the cost between these two approaches, we find that this cryptoeconomic means of of scaling is about 2 million times cheaper than an equivalent uh ZK proofbased approach.

Not to mention latency and centralization that the ZK proofbased approach would add. So for comparison, um, Elves has a latency of basically one block about about six to 10 seconds, right? Um, good luck making a serious a proof of some serious computation like 6 seconds worth of some high efficiency VM um, in that amount of time and for anywhere close to the cost profile. And if you're interested in the numbers, here's some here's some numbers from our um our empirical investigations. Basically, we're looking at around um we can do under elves around um almost 100 million well 100 billion gas ethereum gas EVM equivalent gas per sec uh per US dollar.

And you can compare that to what it currently costs um on two of the uh bigger ZK protocols coming to around 44,000 gas per dollar with the occur with the massive amounts of latency and finality. So this is why we're we're really not that um bullish on using uh ZK methods for uh for scaling computation specifically. Right? That's the first part of my talk. The second part of my talk is uh a different uh uh thing because I was on a plane when I authored it so I couldn't be online.

Um, and hopefully I've never used this app before, but hopefully uh I can make it big. Uh, view play. Okay, play. There we go. Um, now this this is another aspect of JAM that we've been investigating or another aspect of building a blockchain, building a sort of smart contract general purpose computation blockchain uh that we've been investigating.

Um, consensus VMs. Basically it's like you you know about consensus VMs almost certainly you've probably heard of uh I mean you know about EVM Wom is also used um as a sort of a consensus layer for as a sort of virtual machine as an instruction set architecture um there are others um many networks have their own um and we are uh sort of we have one of them uh that's sort of ours which is the the PVM that's a derivative of the risk 5 uh instruction instruction set architecture um and they tend to be slow these things right compared to like native execution and it's important to sort of if we're going to design these things better like better protocols with better consensus VMs at their base we need to understand how they become slow in order to understand how to make them faster and we'll assume for now that we want them faster there are argument I mean I've heard an argument ment that's like ah they don't need to be so fast. All people are ever going to do is like send a balance to another smart contract or another one slightly better argument is um ah if there's like a really difficult piece of computation then we'll just introduce a pre-ompile. But the thing is pre-ompiles require basically governance to be introduced uh to introduce them. Uh and this is hard and um and you also have to work out you know at what point to introduce a pre-ompile and how many you introduce given that once you've introduced once you introduce it you can't take it away and if there's some particular um computation that you want to do uh but that computation ends up being um slightly different in the future and your pre-ompiled does the first thing but not the second thing then you got a big problem.

you basically after we had two pre-ompiles that do almost the same thing. It's not a great way of proceeding when our intention is to build generalpurpose platforms. So um let's start the basics. Why are consensus VMs uh slow? Well, they have three particular characterist we require three particular characteristics in consensus VMs and these are these are kind of slightly weird characteristics.

They're not characteristics that you would typically have found in VMs pre204. Um, and let's think let's list these three things. So firstly, it has to be deterministic, right? It has to be objective and deterministic. So it's got to do the same thing for any given program plus input.

Right? Now this seems on the face of it quite a normal thing to expect. Um but it turns out like not so much. Um particularly for uh physical hardware that will tend to have a single vendor. um they are not necessarily going to define everything um perfectly from a mathematical point of view.

Um now they might want to but there will be instances where the hardware does something different and they kind of just shrug their shoulders and say well I'm not going to change the definition. So you just have to live with the fact that the hardware under these very particular circumstances doesn't quite do what we expect. And this is fine um in you know a fuzzy world where you know there are lots of software writers and they can just basically manage these very very unlikely circumstances by turning it off and turning it on again basically. But it's not so great when we need we have a bunch of um a bunch of nodes um that we're gonna like slash or somehow punish if they don't come to the same answer for any given set of inputs and program. Now point two, we need to be able to limit the work done.

This is also a tricky thing. We need to be able to limit it also under the same circumstances. So that we either limit it or we don't limit it. Yeah. Either this work has taken too long or this work didn't take too long.

But we need to be able to easily um hold this condition in consensus and if it does take too long interrupt it and then basically don't sort of do anything. This is similar to the third uh requirement which is a much more smart contract oriented requirement which is that we need to ensure that we agree on how much work was done. Yeah. Now you know this is uh in Ethereum terminology this will be the amount of gas that is used right or the gas limit. This is a this is a hard one.

Why is it hard? Well, because not only have to we do we have to agree on how much work was done and you'll find um what's called metering um in non-consensus VMs. For example, um WOM will uh there will be a number of WOM implementations that will um have metering. That's not so much the problem. The problem is that we need to uh this metering has to be close has to be close in in terms of um the modeling to the amount of realworld time taken for this computation.

So we might agree that some particular program took 1 million steps to execute and this is the this is information that WAM will give you if you turn on metering in one of the compliant implementations but we don't know how much say an AMD thread ripper 5 GHz um will at core um assuming that there isn't some crazy memory contention or all the rest of it will take to execute those 1 million steps. They're non it's not it's not in any way linear that that um that ratio. Different instructions take different amounts of time. Um and there can be all sorts of circumstantial um situational uh uh uh uh circumstances to uh uh change that to uh to change the amount of execution time. Now this is uh also important to understand.

This isn't about trying to place a maximum bound on the execution time of a program plus input. It's really on a program trace. So it's not that we're trying to get away with uh solving the halting problem here, right? We we totally expect that we will have to execute the program and that's fine. But what we want to do is model for any given program trace like an an execution trace like the specific instructions executed along with the state of the machine at any every given instruction.

Well, we want to um model how much time that takes without actually having to name a specific CPU piece of silicon, my laptop, and say, "Well, that will do it." And we'll have some atomic clock next to it and measure that. Yeah. because that's obviously not very practical in a decentralized network. Um, but in a sort of decentralized sense like we what in a centralized sense that's what we're trying to do, right?

We have a kind of conceptual computer that's modeled uh that's sort of manifested by this decentralized network. And we want a um definite answer to how much um how much time did this non-physical machine take to execute. I mean it's kind of a mad thing to uh to imagine but it's but is literally what we're trying to do here. Now how do these uh how do these requirements um slow us down compared to say native execution? Well the first thing is that we uh we're not using a native ISA.

Now we could use a native ISA. We could just say right we're going to use x8 x64. Screw it or x86. The thing is these come with a lot of extra crap that we don't really need. And um there may be some um some very finicky difficult um ambiguities or worse non-ambiguitities but hardware may not implement these uh standards entirely correctly and this results in uh uh sort of difficult um uh mapping from the ISA to native.

Now the further away from the native hardware that we get probably it's reason seems reasonable to assume that the harder it is to uh uh to sort of get that native level speed. um assuming that we want the same generality, right? If we're only trying to do one thing like I don't know send a transaction or computer um a furry transform then you know it's fine and we just make a totally optimal version of that and then bam um we don't need uh it doesn't you know our sort of instruction set which I which is presumably just FFT with the input um doesn't need to be anything like the native hardware on which it's running because it's only got to do one thing but if we want something that's like true and complete want something that's actually general, then it's presumably going to be a lot faster to make it closer to the actual uh native ISA that this thing is going to be running on. And we already we can we can see this like it's a theory, but we can demonstrate this. We have evidence.

And the next thing that's hard is that the wall clock execution time is not easily predictable. Now, it probably used to be quite easily predictable like long ago in the 486 era and may even still be relatively easily predictable on some types of hardware now, simple hardware basically. Um but if we want this stuff to run fast on modern CPUs on like you know server or consumer grade CPUs that we would find in this laptop or that laptop or some server somewhere then um things become a lot harder and what we're left with is kind of two kind of paths for doing this. One of them is, and they're kind of interesting paths philosophically because they they trade off accuracy for precision. Two words that often a lot of people sort of confuse or mix up or think are synonymous.

They're not synonymous. Um, and this is this subtlety is actually here. Um, one of them is a theoretical estimation, right? This is this is like gas metering. This is where we say right it did this execute uh this it started with this input.

It did this instruction, this instruction, this instruction. Um, and we think it took 15 gas, which equates to, I don't know, 15 nanose, right? Very, uh, objective, totally precise, um, but unfortunately wildly inaccurate for most like for basically any hardware, any real world hardware. The alternative is to get something that's much more accurate, i.e.

be closer to reality, but unfortunately subjective. And this is like run it on your own machine. Run it on the machine that is run it on standard hardware. Get a number. It's probably going to be close to the number that anyone else gets when they run it on their own version of the standard hardware.

It won't be exactly the same, but as long as you take proper precautions, it shouldn't be too far off. And so we have this uh precise but inaccurate versus accurate uh versus uh accurate but imprecise. And it's not always like it's not so easy to uh to know sort of which way to go down. For what it's worth, Polka Dot at the moment, the relay chain of Polka Dot, not the smart contract parach chains, but the relay chain of Polka Dot uses the second method, whereas you know most smart contract chains pretty much use the first method. Yeah.

And that's that's kind of how Polka Dot gets a lot more uh processing done. But it does mean that uh the um at some there is there is in some sense less granularity right there is less granularity. You kind of can't combine different users um of the computational resource in the same invocation. Essentially that's what it comes down to. So it's interesting you know what we're interested to know how bad this really is.

Um, so one of the there are a few different ways that modern CPUs speed things up and do so in some opaque way that's not actually got anything to do with the instruction. Um, caching is a really big obvious one, but there are a few others. Branch prediction, pipelining, and so on. Um, there are a lot of tricks that they use and these tricks are very much well firstly they're CPU vendor specific. They might even be CPU model specific and they are designed to be opaque.

They're designed so that the software can't really tell what's going on. Now there's probably some uh cunning tradeoff between making the the um the consensus level instruction set architecture be um kind of closer to native and further from typical usage. We would assume that the closer it is to native, the faster we can make it go. But the further it is is away from typical usage, the harder the cost model, it turns out. But assuming that we want long-term generality, we kind of have to um we have to be quite close to native because we need the flexibility.

We can't we can't just assume that we know ahead of time precisely which operations um the user or which compound operations, right? FFTs or um I don't know matrix multiplications or whatever the user wants to do. All right. So let's let's uh take it to the the numbers. So we come up with a couple of um uh experiments.

Um and we have at the bottom there we have our sort of platform that we're running computation on. Um, we run it on a native x64 platform, some standard hardware. We also run it under our um, poker VM, our our interpreter. We actually have a poker, we have both an interpreter which sort of goes through and interprets every instruction one at a time. you know the thing and also a recompiler which basically takes the whole program code and recompiles it from um the instruction set of poker VM PVM into native x64 and then runs it as an x64 program um a bit like you know JVM with the JIT except this isn't JIT it's ahead of time so it actually goes through the whole thing and streams out a a native program and then runs that and then on top of here on top of this platform whether it's native an interpreter or a recompiler we run something something useful something something vaguely yeah vaguely useful so one of them is like a char one hash 100 kilobytes of data another one is this mad uh in interpreter inception thing where we actually run a risk 5 interpreter and then inside of the risk 5 interpreter a 6502 interpreter actually a whole nest emulator But the a big part of that is the 6502 CPU.

Um, and then on top of that, uh, basically one of these, uh, hardware test, uh, ROMs that that just goes through and tests all the hardware. And the the idea of this is to make something that isn't particularly well suited to anything, right? It's it's just uh it's a it's a largely unopinionated or the intention anyway is a largely unopinionated um um amount of computation that's probably going to be quite pessimistic um for our uh gas model simply because it involves a lot of arbitrary memory uh reads and we found that it turns out arbitrary memory reads are hard. So we wanted something that was kind of pretty hard to do. We also wanted something that we could recompile uh with solidity and making a risk 5 interpreter.

Turns out it's actually quite easy to make a risk 5 interpreter interpreter in solidity compile it to EVM and this gave us a really nice way of having pretty hardcore compute um but compile it uh comparing it across the board. Now the the for the hashing um we uh we used like a hand optimized assembly version of an EVM SHA1 hasher and we compared this to just uh compiling the standard SHA1 crate in Rust to Risk uh to Risk 5 to uh sorry to either native x64 um or uh PVM. So again, we had um we tried to give uh we tried to make things hard for ourselves and we tried to give uh EVM as uh as good a break as it could get with uh also for example we switched off the bounds checking for the uh for the risk 5 interpreter running on EVM in order to try to you know give it as uh as I say as good a break as possible. Now we had three gas cost models because at the end of the day we can it's all very well metering what instructions pass and we can even meter different instructions differently. A multiply or a divide probably takes more time than an addition.

Um but for memory instructions it's massively dependent on whether the thing you want to load from memory is in the cache or not. And broadly speaking, you've got four uh possibilities with modern hardware. It's either going to be in L1, it's going to be in L2, it's going to be in L3, or it's not going to be in any of them, and you have to go to main memory. Um, and if you choose the right CPU, you'll get about um one megabyte of L2. Yeah, that that's about as big as it gets on the consumer side, but still about one megabyte of L2 per core.

Um L3 it can go into the you know 10 plus megabytes and then after that it's like main memory. And what we wanted to do was um was compare was basically take the ratio of gas to actual wall clock execution time depending on whether we assume it will be we didn't bother assuming it's an L1 hit because it's trivial to write code that can prevent L1 L1 hits right it's trivial to write write malicious code but we did want to compare it for um L2 hits L3 hits and an L3 miss. Um, and we wanted also to compare the difference between recompilation onto native interpretation on native and just running it straight to native like compiling to native directly and running it as native. And these are the numbers. So um basically running as uh running as native um gets us actually I think I think this number is slightly different on a on a yes that should be instead of 04052 and instead of 014 we managed to get that down to 0075.

Um but yeah so uh it's not not too far off after we managed to um we got the right the right code running. Um the native uh is about half as fast as recompilation. It's actually recompilation is a little bit better um in terms of ratio interpreter quite a lot slower. And then depending on how we uh our estimation, if we limit it to um if we make an assumption that we will always hit the L2 cache, which can be engineered can probably be engineered um despite running potentially malicious code. Like this can probably engineered by a combination um of limiting the amount of accessible memory and making um using a memory manager that basically randomizes things on on each of the different nodes so that it's impossible to predict um where two different memory pages are going to be in physical RAM.

Yeah. But anyway, this is sort of CPU stuff, but the point is that it's not unreasonable that we could uh to expect that we can guarantee L2 misses under circumstances that are still usable. For programs that need more memory or whatever, then that would be that the L3 hit would be the uh would be the number to take. And then for programs that, you know, just need a gigabyte and it's RAM. Um that's the interpreter inception the hashing the char one hash so similar right similar kind of numbers bit um a bit smaller about a thousand times smaller um so how do we how do we get these numbers as small as possible because obviously we want to make um our estimations be as close to wall clock reality time yeah as possible They're close.

They're never going to be lower than or they should never be lower than wall clock reality time because that would imply that we are effectively giving more work than the network could possibly do. But they should be as close as possible to it. And at the moment there may be an order of magnitude one to two orders of magnitude off assuming that we recompile. So how do we get it closer? Well, one of them as I mentioned is to make some assumptions on memory usage.

Basically make some assumptions that the L2 cache is always going to get hit. And the way that you do this um in our under our sort of experiments and we've we're fairly confident that this is a viable strategy is to limit the amount of memory available and do some cunning page mapping um uh magic ensuring that they are uh at unpredictable places in physical memory and therefore that uh code that guest code that's running cannot uh know which bytes it should hitting in order to cause um uh collisions on cash lines. But there's another thing that we can do. Economically sound augmented metering is what I've very quickly named it. Um and this helps us make up that gap a lot um further.

Essentially what we want to do is apply a metering factor, right? So we want to say um we typically non-malicious code is not going to run at the speed that we assume malicious. This is kind of assuming it's malicious. Yeah. And normal code most of the time isn't going to be malicious.

We cannot assume that it's not malicious as long as it's as long as anyone can run any code by paying some baseline amount. But what if they didn't just pay a baseline amount? What if they put some sort of stake in the system such that they lost their stake if the code turned out to be maliciously engineered and take a lot longer than um the you know the the lower estimates, the lower end, the top two sort of well the second line down basically. And this um this becomes like an economic um answer to the problem. Essentially we keep our objectiveness because we have an objective ratio that we arrive at through economic means and we have an objective gas metering system that we arrive at through purely computational means and we combine them together to get a final objective time.

And this makes up for the fact that we can't get close enough in a purely computational fashion. And this is not unexpected. Hardware, CPU hardware is complicated AF. pretending that we can write software that can like understand what the CPU is doing under the hood and come up with a number as to you know that that reflects the time that it will take or that it had has taken is uh is unrealistic. Um and therefore our only reasonable course of action is to move into the economic domain where we can reasonably believe that if someone hasn't written code specifically to break our gas metering system um then they can probably be sure it's going to be not far off the average sort of expected um time.

And you know if they care they can measure it themselves under the input uh or class of inputs that they expect and get um uh become more confident. So we need two things basically. We need a means of disincentivizing malicious behavior, disincentivizing the engineering of programs that um uh take longer than our gas metering plus ratio uh would uh suggest and the means of working out what ratios will ultimately be able to be considered valid under consensus. So we have to get some agreement on what ratio is valid um for any given program execution. Now it's easy enough to form a disincentive, right?

You take a stake and you just say we'll slash it if we agree that it's uh the program took too long to execute. But how do we decide that it took too long to execute? And furthermore, given that we then we have a method for deciding how do we ensure that whoever is going to be staking can be confident in that answer in that solution in that decision want to make sure that the judges are not going to be biased against you if you're putting some your money on the line. So basically it comes down to three parts. subjective measurement which is where um the staker themsself um um actually measures how long it takes for the for them on their instance of the standard hardware.

um statistical consolidation where those judges the validators in uh in essence um measure how long it takes on each of their instances of the sand uh standard hardware and then uh statistical uh consolidation of that into a single value and thresholding and in principle it doesn't need to be consolidated into a single value. it could be consolidated into some sort of uh distribution and thresholding applied to that. And then we come up with basically a confidence bound as to how likely it was that um that the ratio was intentionally breached. And if it was intentionally if it was very likely it's intentionally breached basically because everyone agrees that the real ratio is far worse than the stake ratio. Um then we slash more.

And if it's if it's not particularly obvious it was intentionally breached but it was probably breached a bit then we slash less. Now this mechanism in a lesser um uh sort of imagining is already practically deployed and has been deployed for years in polka dot. Um, and this would represent a slightly more um sophisticated um reimagining of it that would give one very particularly useful thing which is objectivity over the amount of gas used. And this is because we have the linear relationship now because we can comp we can um take our ratio which we know is going to be sound because of this incentive structure and our gas metering which we know is objective anyway and combine the two on polka dot. We can't do that.

So let's compare let's see what this gains us. Let's compare it to uh uh to a couple of imple implementations of e of Ethereum nodes and EVM. Um, so you have a couple of implementations there. Um, and we're comparing this to uh uh uh our uh PVM essentially our jam implementation but our poker VM implementation for PVM. Um, now this is for the interpreter inception.

There are similar numbers for hashing. Um, so the native wall clock time is the amount of time that it took for this to run when it was compiled to native. Right? So we took our uh risk 5 interpreter, compiled that to native, ran our MIPS uh sorry not MIPS, our 6502 interpreter, our NES emulator on top of that, like within that as a guest program. And then we ran the m the NES test ROM inside of that as a guest program.

And we came out, we ran it for a frame or two, a few frames, and we came out with this uh it took uh half a second to execute. Okay, now we move into the consensus VMs. So we um instead of compiling our risk 5 interpreter to native and running that with the guest with with the guest the guest we compile it to we make a risk 5 uh uh uh implementation port well it's ported to solidity and compile it into EVM and we run it on one of the two Ethereum EVM um um environments implementations. Now, they both obviously reported the same gas taken, so fine. It's not that relevant at this point because it doesn't obviously correspond to any particular time taken.

I mean, once it did when we were figuring it all out in 2015 trying to work out how much gas represented, you know, a second of computation, but doesn't really make any sense anymore. Um and then we also uh check to see how long it took like wall clock time to execute the same workload. So what took 0.5 seconds of 0.52 natively um took uh 654 seconds when ported and ported reasonably well mind um to solidity not like some dodgy highly pessimistic port like did our best to actually make it run fast.

Um and 102 seconds um on how do you pronounce that? Eth one Ethone. Um, and then if we work it through like the amounts of blocks that this would take um to actually uh do this workload on an on an Ethereum chain with similar parameters to the Ethereum L1 then it would take about uh 4 and a half thousand blocks which again with similar parameters to ETH L1 will take about uh 55 a half thousand seconds. The slowdown therefore so that it could be attributable to the change in ISA the change in machine spec is about 200x for uh ETH1 EON and uh 12 a halfux for GE. So GE is quite a lot slower, right?

It it it introduced a much greater slowdown um presumably because its EVM implementation isn't as fast. um the amount of slowdown we can attribute specifically to the protocol. So given an implementation an EVM implementation's um speed of execution for this workload, how much longer does it take the protocol to get through the workload? Um, well, GE does better on this because of course uh it slowed down a lot more at the uh at the sort of ISA stage. Yeah, his EVM just basically runs run stuff slower.

So, it doesn't seem as bad that um it takes longer for Ethereum to actually process it on chain. And that that can be attributed to about 85x for GU and about 5 40x for Ethone. And then if you multiply these together, um, you end up with the same figure, the total slowdown, which is about 100,000. So it takes about a 100,000 times longer to do computation on Ethereum than it does to do the same computation natively. Yeah.

So let's compare this to PVM and see how much better we can get. So again, the native is the same. Yeah. It doesn't make any difference here. Now we have we have a gas.

Now the gas in um in PVM is spec is specified as being the maximum worstc case time uh taken for execution. Yeah. So the maximum time taken maximum worst case worst case time maximum time for execution. In this case, Poker VM alone um without the this like additional um sound or um uh augmenting uh augmented metering um the is 18.7 right this assumes NL2 uh L2 hit.

So it takes whatever that works out as 35xish um as much time or it's 35x worse um our objective uh that our objective um estimation is compared to native. Now how long did it actually take to execute 8 seconds right? So actually not far off native, like really quite close to native. Um fairly impressive we would say. Um but unfortunately this proximity to native um is only half of the solution.

We need to ensure that worst case we can predict uh our worst case estimation is also close to native. And in this case it's hard. So our effective VM slowdown from this is oh that should not say oh no yeah our effective VM slowdown for this is one and a half right because our VM is takes about one and a halfx longer than running it natively. This is pretty good right this is pretty good. But how does this work in terms of protocol when the gas model kicks in and the block limits kick in?

Now for block limits is actually pretty good because um in uh JAM the all the work is done essentially asynchronously by the worker nodes by the sort of validator nodes. Um and therefore the amount of work that validators can sort of get through is uh the same as pretty much like theor is the same as the warlock time as long as the as long as the gas mechanism is sound. Right? So it has to be sound but because it's sound it can be the same. um we don't need to account for a bunch of the other stuff that would uh result in most chains um having lots of space having sort of you know doing a lot less compute even in terms of perfect gas timing uh because all of the jam work is sort of done asynchronously pipeline there's a lot of sort of optimizations so let's look at the protocol uh let's look at the gas time so it's our gas time is uh around uh 18.

7. So we our our sort of best estimation that is sound right that is not is definitely not um attackable is secure is 18.7. In reality it only took 0.5 but our best our best secure guess is 18.

7. And therefore that's where we get our uh the bulk of our protocol slowdown from. In fact there's a little bit more than that because our uh our VM did take longer than native but only a little bit longer than native. So it ends up being for the protocol slowdown portion only about 23x and we end up with a total slowdown of 36x for um uh for the sort of full um after all is considered. Now if we introduce the uh this sort of economic mechanism for bringing that ratio down um which assumes additional stake right so there's like it's probably the the person who is uploading the code is going to um be somewhat or providing the inputs is going to be somewhat uh um equivocal on how much state they want to put in like how much they want to bet the ratio is better.

But in principle um this can be reduced to a very very small factor slowdown. Um in principle you know two 2 and 1/2x slowdown which um would be pretty um pretty good. This would allow for basically two and a halfx native oh whatever 40% 30 35 40% um native speed. The uh numbers for the hashing are a little different but not too far off and we see sort of similar uh hashing is actually a bit a bit of a harder task it turns out. So for the EVM uh sort of Ethereum um side it's more like 300,000 and for the PVM side it's uh the best case is closer to 4 and a halfx.

Um, good. That is uh the consensus uh pessimizations part. Now I'm going to skip back to the other bit, the other slideshow. Right, I want to talk a little bit about core VM. How much time do I have?

Not so much. Uh, right. I'm gonna really go through this fast because I wanna um so uh jam is progressing. We have tooling. Uh here's lots of uh screenshots of tooling.

Um there's like uh jam breaks down into having two bits of logic for its smart contract if you like. One of them is a really fast prep-processor that we call refining and the other one is a um still quite fast inconsensus uh uh processor called accumulation. Um basically we have do lots of refining in parallel high performance um every block and then all of that comes together kind of fan in uh and gets all combined um as needed in accumulate um good um core VM is a means of using this. How does it use this? basically allows in the refine stage, this very high performance but largely stateless stage, it allows um a virtual machine instance, basically a a a guest instance um of uh of a very regular virtual machine, PVM.

Um so for if you're not familiar with PVM, you're probably not. Um it's very different to EVM in that it's not stack based, it's register based. It has regular memory, 32-bit addressable. Um, and uh, and it's metered and it's fast like all I just sort of mentioned. Um, you can compile regular code to it, right?

Um, so it turns out that because it's risk, you know, it's risk 5 compatible. So it's basically a derived ISA from risk 5. when you actually build code, you build it to Risk 5 and then you just run a sort of um a Swift onepass uh uh uh recompiler and it turns it from risk 5 into PVM. PVM is essentially a pre-processing step that makes it a lot easier and more optimal to then recompile it further into X64. So we're kind of using risk 5 and PVM as intermediate targets um to make it uh that are good for consensus code, good for gas metering um but not as uh bulky and potentially ambiguous as straight x64.

And the great thing about having uh guest VMs is that you can um at least ones that you can read the memory of um sort of peak and poke into the memory is that we can uh pack up the VM execution and then start it again in the next block in some you know stateless way um such that the guest of that um uh virtual machine doesn't realize it has been stopped and restarted. This gives us the uh apparent continuous execution for these guests. So you can think of core VM as essentially a sort of docker uh sort of container for um regular software, regular sort of a regular machine. Um how does it work? Well, basically it sort of initializes its um registers to like zero.

It's program counter to zero. Empty page table memory is empty. Um it sets the code. It's a um it's a Harvard architecture machine. So the code sits outside of memory and then it basically just advances it um uh either just doing regular computation if if it doesn't need to read anything from memory.

Um if it gets out of gas, it basically just snapshots all of its memory and sticks it in the data lake, a big data availability system that the jam provides. If it's a page fault, it tries to fetch the d the the data from the data lake um or introduce a zero page in the table if there isn't already a page in that place in memory. And on a there are host calls that allow it to output data basically to uh in a sort of I don't know kind of output like graphics card sound card kind of like beyond the machine some some destination for data beyond the machine and we provide this through a particular host call almost like a a sort of um an operating system um uh sort of uh call um and I'm going to go into the architecture particular ly it's uh I don't have really time. Um so there's a bunch of tools um a tool for um monitoring this these output streams. So virtual hardware um a virtual uh monitor virtual speakers etc etc uh virtual console because of course we want regular software to run in this um and a builder which basically just works out is a memory manager basically it works out which memory pages are needed for any given um uh uh sort of execution slice of the machine.

Uh right. Let's see if I can make this work. Um I I sort of have I I thought everything was already set up from the last uh what's it the last presentation I gave and then it I sort of turned the laptop on just to make sure that it was all ready and waiting and then it turned out that um I had uh installed a different distribution and of Linux and uh didn't really have a uh well didn't have any kind of setup on it. So I very quickly 15 minutes before coming to this talk tried to set everything up again which took um I I haven't had time to actually test it. So uh it may or may not work.

I mean I don't even Oh wow. It's actually is that No, I need to mirror it. How do I mirror on here? Uh settings. Settings.

Which of these is settings? Uh application settings. Ah here we go. Settings. Displays.

Uh, external display mirror. Um, mirror. Does that work? Yes. All right.

Going. Uh, right. Now, um, so I'm going to start a test net. No, I'm not. Oh, dear.

Uh, this this doesn't usually break. What is going on? Ah, yes. Okay. Now, I I see.

I just have to run this um this mad uh line here and probably I need to sudo it and then run the test net. Okay, so uh the test net is sort of started and it's doing a thing. What what this has done is spun up six nodes on my laptop and then each node is running a is is a jam node. So they're all sort of talking to each other. Um, and then I've got this program called jam top.

Uh, which is a bit like top. I don't know if you know top, like it's a Unix utility. It shows you what's going on on your machine. In this case, there is only one thing going on on the jam machine, which is this bootstrap service. Um, the bootstrap service is basically like a BIOS or or whatever, like a firmware that lets you load other software onto JAM and kick it off.

Um, now, uh, the first thing I need to do is load, um, some data onto, uh, JAM. Uh, which I'm going to do this. This starts Oh, dear, battery is low. Uh, this starts a, uh, well, hopefully it's it's not that low. Uh, okay.

19%. We might be okay. uh it starts a um uh a virtual file system on on jam on the blockchain and uploads some data to it. It takes a little bit of data. So, it's going to spend a little bit of time uploading.

Um and you can see the upload happening basically with this P flag here. I don't know if you can see that. No, you can't. It's really small. Um I'm not sure why it's so small.

Maybe I can make it bigger. Um bigger. How do I make it bigger? uh 14inch laptop display that's like project to resolution. Yeah.

Don't know anyone know how to use this like cosmic thing. No. All right. Uh never mind. Anyway, so uh that has been now uploaded.

You can just see that's finished there. Um, and what we're going to do next is, uh, make a new VM. I'm going to copy from my cheat sheet. Um, now what this command does, you can't really see it, I'm sure. Um, it's it it starts a uh new VM using this jam tool, JAMT, which connects to the network just to one of the it actually spins up its own node.

The node connects to the network. um it uh introduces a new process into JAM and then that process is um uh is is this core VM process this kind of docker if you like and then it immediately takes that process once it's been created that sort of executable and tells it I want you to start this other guest executable inside of your container. Yeah. So it's a bit like saying docker I don't know with a Linux thing and then start I don't know Apache right it's a bit like doing that on in DevOps terms um let's see if I can make this at least a bit bigger control plus I'm on Mac usually so this is huh made it bigger for me oh nice okay cool uh can I make it brighter No, I don't know. Don't want to I don't want to jinx it.

Maybe they can make it brighter. Maybe the the gods of the projector can make it brighter. Uh, okay. So, that that that's that's completed, right? So, what that's done is it's just basically, as I said, created this kind of VM container and then initial initialized it with um a program.

Um, and we get given the service ID. This is just an this is like a process ID, right? So if you're on Linux or Unix, all the processes that are running will have an ID. It's like a number. And this it gives you the same thing.

You can see it down here. You can see the same thing up here on Jamtop, right? It's the same thing. And if you I don't know if you can see it, but it's like it tells you on Jamtop, right? There's a VM.

This this service is a VM and the thing running in it. Uh well, that's uh that's this that's this thing here. Um, so the next thing that we need to do is we need to connect a uh the output of this docker to a to an actual monitor, right? To something so we can see what's going on inside of the Docker container basically. Um, and that's what we're doing here.

And in order to in order for this this guy to sort of know what it's uh what uh which VM it should be connecting the monitor into, uh, we need to give it this ID, right? this process ID, this service ID. So that's what I've just done there. And then what I'm doing here is I'm telling it to start actually uh ticking it along. Yeah, cuz someone's going to have to sort of pay or whatever for this thing to run.

It's not free. Uh network is unreachable. Right. This I remember this program from before. And this is because I don't have WiFi.

So let me put WiFi on. Um, do we have a I just use my phone. Uh, right now when you're doing personal hotspots, you need to go into the settings and like flick this personal hotspot thing and eventually it should turn up, right? I mean, maybe there we are. Okay.

Connect. Connect. How do I connect? There we go. Is that going to work?

[Music] thinking about it. Still thinking. Okay. Do we have a password for the protocol berg nets work or any of these really? Is that a right pro?

Oh, Department of Decentralization. Okay. I don't know that then. Department of Decentralization. Okay.

Right. [Music] Okay. Is that going to work? It might have worked. Looks Yeah.

Let's see. No. Network is still unreachable. Does that mean it's connected? No.

Right. Okay. So, we have the monitor there. We have this there. Yeah, it's got this dot dot dot thing going on, which I'm not I'm not confident means uh connected.

I'm going to Okay. Right. I'm going to turn it off and on again. And hopefully All right. It's off.

Airplane mode on, right? Airplane mode off. Wi-Fi on. Department of decentralizing. Why is this white thing here?

It's not doing anything. I've got a feeling that it's like breaking at the Uhhuh. protocol. Okay. Yeah.

H. Um, right. Well, I'm afraid you're going to be denied the uh uh the cool um thing, but this is a um what it what it was going to do is send a bunch of um or send work packages into the JAM network which um ticked forward this virtual machine and uh that would have resulted in output going into the virtual monitor which was going to um uh moni which is monitored by our u monitor program here which would have uh made a window and displayed what was going on in the machine and if you can read uh that there which you can't really uh it would have displayed the game quake proceeding good uh well not really but um no it's not it's it's it's like definitely not happy with the network Um, good. Right, that's about all I came to say.