JAM

Transcript

[Music] okay and we're back uh the next speaker does really not need an introduction but for the sake of completeness I will introduce him anyways it's Gavin wood he is the co-founder of ethereum and the co-founder of pad do and today he's here to talk about the gem chain gem stands for join accumulate um machine yes thank you all and um that was recently proposed and published in the gray paper and I'm sure he can explain this all much better than I can so please welcome him on [Applause] stage thank

you some pretty cool uh visuals there uh always nice to see the uh ethereum logo being uh altered in these various ways lots of uh uh lots of imagination right uh Jam yeah um join accumulate machine it's a uh protocol um that I've been um kind of working on for I don't know I guess uh N9 months or so now I put forward the uh you might have heard of it I put forward a gray paper which basically details the protocol formal definition um maybe not quite the

final version but you know final enough for putting a paper out and uh I want to give you a bit of an overview of what it is and uh you know maybe draw some parallels to stuff that you're more familiar within the ethereum ecosystem so uh first the uh driving factors what was the point of the work I mean it's it's the same old stuff really uh that you know it's 10 years now since I've been working on this stuff um and I guess over the years you kind of think a bit more you kind of ask yourself these questions what is it that I'm working

towards you know uh what's the point of all of this and uh you know every now and again I I sort of put a paper out and I try and sort of uh get a bit further down in the weeds as uh as and and and and a bit more sort of clear as to what it is that that trying to deliver and in this particular sort my latest iteration of this are these five points right and I think the five points are kind of interesting because if we if we look at like the um the progression of of web 3 protocols um we do see some of these um

uh some of these things appearing and kind of in this order um I leave accessibility aside for now but like resilience this I think is the the key um uh property that web3 systems need to have right if they're not resilient they're not web three right it's kind of the kind of the point of this um and Bitcoin was like a truly resilient system and it was also coherent right coherency is a is a crucial one um and I think you know with ethereum we we took that resilience and we added generality to it I think you can sort of see that as being sort of a fairly obvious narrative that you can uh

attribute um performance sort of came later and you know I'm I'm kind of missed the polka dot so I'm going to say this uh you know performance is something that I believe uh polka do brought to the table uh Beyond resilience and generality um but the problem or one of the one of the identified problems with polka do that I would say is uh coherency and this is uh this is going to be a sort of theme of The Talk um by uh introducing performance coherency um suffered somewhat and specifically what I'm talking about is sharding and sharding

spec uh sharding through a persistent fragmentation of state and having a persistent fragmentation of state only leads to very very very eventual consistency coherency um I mean no that's not quite right consistency is is is fine but coherency which is basically the ability for one state somewhere in the system to have an effect um on state somewhere else in the system the reality is if it's in the same Shard that effect is could be synchronous uh can be immediate uh but if it's in a different Shard it's a lot a lot more painful a lot um a lot slower and uh there's a lot more

contention between how many things can in terms of cross state interactions can happen um and this leads to a principle that I'm sure exists and it's a very it's not a principle specific to blockchain it's a principle that you can find all over the place throughout all various sort of disciplines uh Computer Science Biology physics you name it you can generally find this this principle size synchrony antagonism and basically it means as the system grows it's harder um for the uh interactions between the elements of its state um to happen in a synchronous or coherent F uh basically things tend to split up into their own little um

segment and it's it it's the job of uh protocol designers and system designers to try to not let this uh as as systems grow which we assume we generally want um to not let this result in a very uh uh uh asynchronous or or incoherent um uh eventual uh situation so jam is uh generally coherent with transient decoherence I I I would argue that if you want something to be decentralized resilient um uh unless you have some extremely

clever new stuff to bring to the table probably you're going to have some degree of coherence reduction it's not going to be you know a classic uh let's say ethereum L1 model where where you've got like a play pen that everything just has uh uh synchronous access to everything else all the time uh you're probably going to have costs dependent on which particular State um uh uh element that you are and which one you want to interact with however what we what we really want to do is reduce um this decoherence to limit it um jam does this by um essentially splitting computation into two um

part um in core computation which you can imagine is like computation that happens in the rollup so to speak um this has access to a decentralized data Lake um but it's otherwise fairly stateless and then secondly onchain computation uh which is State full has access to the onchain database and the basis of the coherency is this like um uh refine accumulate split um yeah okay so we have we're able to um by splitting up uh the state and and and well no by splitting up our computation we're able to have like

these separate computation elements um we call these cores you can think of them as being sort of separate rollups and we allow um a decentralized data transfer or direct data transfer between these cores and we do that through placing the data into the decentralized data Lake and then bringing it out again we do this like part of the protocol so this isn't something that l2s that are building on Jam need to be particularly concerned about they can just use cryptographic commitments basically references and pass those around rather than having to actually drag the data out of the lake repackage it up and put it back

in so you can think of jam as a rollup host and a rollup reactor so it both hosts the rollups and it allows their um uh their outputs to be sort of reacted together into a single coherent State and you can see in this regard rollups as a sort of pre-processor but pre-processor with a common access to this decentralized data Lake um the data Lake isn't quite isn't perfectly synchronized so it's not like you can uh put data in the data Lake uh at time T and then have it uh be available to everything at time t + one um but there are ways of uh ensuring

that uh if it goes into the data lake at time T um you can have access to it at time t+1 if you're careful and will generally have access to it at time t plus2 or t+3 otherwise and we're talking about blocks here so um uh that's all factored by 6 seconds um we have an algorithm called elves which is basically our rollup algorithm you can think of it as a bounded security optimistic rollup and we have consensus algorithms um kind of similar to uh uh uh to uh ethereum it's it's a hybrid thing we have one for the block production and one for

finalization um if you want like a picture here is my uh very roughly handdrawn um uh picture of like what the jam uh uh join accumulate machine looks like so we have this idea of this outer ring that has transient decoherence basically means every within a sixc window um these individual computation elements don't know what is going on with the other computational elements so there's there's no synchronous interaction between computational elements however that ends after that 6C everything gets folded into the Reactor Core um which is in the middle that's fully coherent has this database that is uh that is uh you know has pretty decent

uh access characteristics um and then the whole thing starts again in the next six seconds and the transient uh uh this transient decoherence has access to this like very very large data Lake 1.6 paby uh data Lake um so the jam data topology it's not a Circle it's not like this sort of singular sand pit um it's uh and it's not like polka dot either where it's got lots of singular sandpits all sort of connected together um in fact it looks more like a flower so it's got these kind of petals and they each share a bit

in the Middle where they can do synchronous uh consolidation like fully coherent consolidation um but within the the broad the bigger part of The Petal which is where most of the data access and communic uh computation happens um they are um they operate independently this is how we scale out right you got to scale out some way um we're not scaling up we're not just like making the validators faster um we want to actually parallelize the workload across the network if you want to sort of zoom in a little bit this is like kind of what a a a core looks like or one of the petals um some of these numbers are a bit out

of date but it gives you a sort of rough idea um basically the cuse these big the big part of the petal this is where all of the real heavy lifting happens um and it can pull in about 2 megabytes a second of data and also push out about 2 megabytes a second of data to the data Lake um security wise they're equivalent uh that's that's why we have our our our security system um and then in the middle uh the smaller part of this the the the two The Blob um that's the thing that gets shared with all of the other petals all the other small bits of The Petal and um that's where the this

singular sort of database exists you can think of that as sort of like more like the onchain part um oh dear this is the old PDF I gave a second PDF uh do you think you could you can find that Obie I air dropped it to you y all right good um there are a few extra slides and unfortunately Ely

things are in a different order I thought the order was a bit weird but yeah um so the jam the jam protocol that's that's more or less a uh an overview of of of what it is um I think a more important thing I wanted to sort of talk about is umbe maybe not more important but somewhat similar important thing I wanted to talk about was the uh approach

that we're using for me the approach is a um it's a bit of a return to to uh Nostalgia 10 years ago um you know one of the things that uh I think I think was really fun doing 10 years ago with uh you know vitalic and Jeff was like this co-development of implementations of the same protocol something that I generally call a uh protocol first um development strategy basically where you put forward um uh what something should do and don't worry too much about how it does it and

let aha uh no no this is this is not it second PDF guys pedia um and you put forward a um uh uh yeah you put forward what what it is that the thing should do but you disregard um how it is actually going to do it and you let people figure that out now it's crucial to be very disciplined when you're doing this um you need to uh not fall into the Trap of of saying well you know this uh development team is is is very good and we're just going to develop the thing and then um hopefully other people will also develop something and it'll be

kind of compatible um this is sort of what we did with uh to some degree this is what happened with polka dot where the the software came first the implementation came first uh the protocol was specified um um following that and then implementations uh sort of came following that and in reality implementation's never caught up um with Jam the approach is is very different that's partly borne out by the fact that gray paper exists before there was an implementation and uh

partly um through a number of additional things that we are okay all righty uh additional things that we're doing to um uh uh to help uh encourage this so let's have a look all right um so we have this idea of like um the gray paper protocol specification secondly the jam prize which is basically a fund um that we are going to just like hand out very clear rules as to how to get it um based on the implementation of the gray paper and

the jam toaster which is basically a a common shared piece of hardware on which each of the jam implementations can kind of interact and uh and and sort of test themselves and and trial themselves and uh analyze their behavior so yeah the gray paper um it was It was kind of fun to get back into writing um a formal uh blockchain spec I really done it I never did it for polka dot um and um yeah there are I I I it was really an effort to um uh to make it readable for for people

who are very um familiar with um sort of the yellow paper and it and its its formalisms and its notation um and I view Jam as being um kind of equidistant between polka dot and ethereum in that regard it's uh many of the elements um many of the opinionated elements of polka dot have been removed and really tried to pair back the protocol into that which is really um just which is necessary uh to be at the base layer um the prize is like uh a bunch of um a bunch of dot KSM it's like separated into Milestones basically

again just sort of easy on ramping um and there's one of the things that's like additional to the the the actual um uh uh uh crypto incentives you know one of the things that that polka dot has really been pushing I think that that that's kind of nice to um to see happening uh is the fellowship so for those of you who are not familiar polka dot basically has a Dao um that that exists within its sort of system um and one of the key elements of its Dao is is um kind of what we've called The Fellowship which is a little bit like a

uh a a company maybe in the old sense of the word um a company at Arms um and this uh Fellowship can provide onchain salaries in stable coin it's funded by the central Treasury and it's very much without any kind of um uh help from centralized real meat space um uh organizations it it exists as a purely onchain concept and it's actually like employing people not not in the official legal sense of the word of

course but it's giving people regular monthly usdt salaries um and that's something that I'm hoping to leverage for um uh you know for Jam implementers there's a few other bits in there but um a lot of this stuff is is is uh maybe not the professional audits but the international seminars this this is sort of from the ethereum world that like you know when um eth 2 was just starting to be implemented I remember um we went to I actually went to one in Taiwan it's quite good fun I think it's a good idea um and even the this like fellowship and salaries and deification of the protocol is something that uh you know we we were discussing um on the basis uh of

ethereum foundation ultimately becoming a DA back in 2014 so it's none of this is especially new to the uh ethereum Community or mindset but I think it's something stuff that's important and stuff that we should be pushing forward um lots of different languages not going to go too deeply into this but basically um another another thing that we want to do like decentralization takes a lot of different forms right there's protocol decentralization trying to make sure there's many different validators who are helping um uh uh uh maintain the pro maintain the the the state of the system um pushing it Forward block by block and so forth uh but we also have to look at

like human decentralization it's if you've only got a single team behind something or only a single language that's really ever used in in a in a protocol then it it doesn't help its resilience and so one of the things that actually really want to push is to have many different languages uh bringing in many different um paradigms of of uh implementation um into into the jam protocol and uh yeah like you know you got uh crazy code at the bottom that I don't think anyone's going to implement um a block importer in uh in whites space but I put it there maybe there's

some crazy people that think it would be fun to do um jam toaster basically just a um a cluster that can um host a fullscale jam Network 1023 nodes um so yeah this is something that we're building out and hoping to uh um get some real testing to make sure that the numbers that we are uh aiming for are indeed realistic so uh unfortunately this bit of the talk I've already done I was meant to be the other way around um uh but let me see if there's any bits in here that I can uh I can talk about a bit okay yeah so in in in Jam just to

give some maybe clearer idea as to what it's actually providing so you're familiar with smart contracts which are basically objects in a objectoriented programming language object environment perspective in Jam um these things are called Services um I could have said smart contracts but I think it would have given the wrong idea um cuz the services are a bit lopsided smart contracts are generally very coherent within their immediate environment services are not um a service uh like a smart contract is per permission unless you can create a service without any real any any permission it's pretty cheap um but the code has three entry points

unlike a smart contract code which has just one and then separately you kind of use a a decoder to try and um you know simulate multiple entry points but in reality a smart contract only actually has one um what it does when it gets a transaction or a message call um uh Services fundamentally have three refine accumulate and on transfer so refine is basically the big part of the of the of the blob and it does the that does the roll up and it's stateless other than access to the decentralized data Lake and there's actually a static lookup system as well and then accumulate can think of as the small bit of The Blob and that's actually to integrate the

output into this shared um super coherent State and it actually has an extra bit which is on transfer split apart the accumulate on transfer uh for regular like ethereum style smart contracts accumulate on transfer would actually be the same thing indeed refine accumulate non transfer would all be the same thing um it is permissionless so um it hosts the jam chain hosts all of the all of the stuff just like um an evm style chain would uh would host code data State um there are deposit requirements so there

are no direct limits other than economic limits but you actually do have to if you if you're uploading code and data then you have to like actually have funds in there uh you know basically to provide in uh to uh prevent indefinite State growth it's transaction so jam does not solve stuff like sequencing or anything like this it's really just there as uh in the very basic sense of being kind of um very very parallelized quote unquote decentralized supercomputer um there are extrinsic information fed onto the chain obviously uh but they're not user transactions they're actually only they're validator

generated data and it's just to allow the validators to have a central coordination Point um I'm not going to go too deeply into the refine accumulate on transfer model but you know there there it is um the other thing I'm going to uh do a quick quickly mention is the uh pvm so this is a uh with with ethereum obviously there was the evm with polka dot we used web assembly as our as our sort of standard language for expressing what computation needed to be done um in Jam we're moving over to the pvm uh pvm is a risk five

derivative ative um it's it's very much based on risk 5 on a 32-bit uh variant uh but it's um a few things have been moved around they're all very thing very easy things to to take uh for you to take risk 5 code and turn it into pvm code so we can reuse all of the risk 5 tooling it's a very simple static translation doesn't take long one to one basically um but it's important to allow us to do what we want to do with it um if you're not familiar with the risk 5 Isa it's little Indian 32-bit registers um 32-bit addressable memory 4K Pages

although you can actually alter this um basically it's pretty similar to x86 um and it turns out that if you uh if you use the uh the the regular version of of the risk 5 Isa has uh 32 registers uh but there is an embedded version that uses that has only 16 registers now unfortunately x86 only has 13 usable registers uh but it turns out that one of the 16 registers is the zero register so it's always zero so it doesn't really matter we don't need to do that one we can we can uh do that in other ways and then two of the registers are operating

system reserved registers so the compiler has never actually used those two registers which means they only actually use 13 registers which are the same number of registers that we have on x86 what this boils down to is that um risk 5 or at least this specific version of risk 5 can be very easily translated into x86 native code and indeed it can be done so um with a in a uh streaming compiler um that that is uh order n in the in the length the program now we've got a a streaming indeed a streaming recompiler um and we found that you know we can get this recompilation down into

um hundreds of Nan hundreds of nanc it's definitely a nanocs per instruction anyway um I think it ends up being a few tens of millisecond uh microsc for um sensibly sized programs um and uh the a very interesting additional thing is that the metering can be done much closer to the time spent on the underlying that the underlying Hardware actually um uh uh needs to compute um uh the program um and the way that we do metering is kind of Cl we sort of do all the regular stuff chunky instructions together into sensible blocks um and uh

and we actually use the floating Point Unit to do all of the arithmetic for um for the metering so we end up with a synchronous metering that costs somewhere between 5 and 10% um or 2 and a half to five percentage points which is pretty decent so we're ending up like with Native performance that is of the order of magnitude of about half sorry end up with performance that's about half of native um and it doesn't go down too much uh when metering is enabled which allows us to do all sorts of really interesting stuff basically we can push an awful lot of computations through and still have um uh consensus sensitive um computation results so the pvm is a pretty major um uh Innovation that jam sort of uses to

really beef up the amount of computation it can do beyond the this 341 X through um core parallelism um the authorization model is a little bit um it doesn't use gas I mean it doesn't use a gas price it doesn't use like per transaction purchases there are no transactions so it can't um but it also doesn't use um this like longterm core rental stuff that polka dot um that polka dot does currently that being phased out but um that's what it launched with um in fact it uses uh what's called agile core time which is somewhere between the two it kind of supports both

models um essentially um it has 341 different cores each each one of these have an index and CES are sold um on a month-by-month basis in an auction um but then there is a secondary Market that allows these this monthlong access to a core to be uh carved up into into bits um to be uh interleaved uh straddled and then um once you once you've once you've got like a bit of the core that you want to sell you can then uh trade them around like nfts and once you want to use a piece of this core time um you can assign it to an

authorizer which is basically just a function that sits on chain and returns either true or false depending on what work you want the core to do and you can write that function so that um it will recognize the work that you want it to do uh return true for that and then the guarantor basically the network knows that it that's a piece of work that it can do um on that core and uh yeah so basically you've got for every core you've got a um a function that tells it what works it's allowed to do at any particular time now this is a little bit of a simplification because we have other ways of making sure that if uh that we don't need quite such a high degree of synchrony but this

is the basic um the basic way um and then finally uh rough limits we do require ire some pretty beefy validator nodes but they should be within regular validator operators reaches um you know less than a gigabit up and down on the network 16 core decent spec machine 64 gigs RAM and some decent um hard disk and roughly speaking what what you get for that is some basically like a super computer I it's not really comparable with with modern supercomputers but it's a lot more than a workstation anyway um about 150x of native CPU speed so if you want some sort of arithmetic

operations per second that's about 600 gigar Ops per second um a decentralized data Lake of about 1.6 1.7 petabytes in total data stored and that can be accessed at about six 6 or 700 megabytes a second by the overall Jam um uh uh code that is running on Jam um and it has a synchronous database sits in the middle this is what you might call like the state the state access and this um should be around 60 megabytes per second in terms of Total Access into that core and about one Mega 1 million operations like read right accesses uh also per

second for the whole of uh for the whole of jam um it's agnostic to any of this stuff uh it it it it's it's actually agnostic to transaction and transaction sequencing as well didn't put that in there but yeah staking is left as a higher order thing to be done on top you know in whatever Jam is actually um um Computing economics it's like whatever that's that's a opinionated thing Jam doesn't have any opinion governance same good that's the talk thank you thank you for this very comprehensive uh introduction to jam um please stick around because Kevin will

also be joining us on stage at uh 10 1 again for a panel with vitalic so if you have any questions I'm sure you will find him around and um I think we are doing a break so we will be back shortly