Polkadot's Future: The Big Jam - TOKEN2049 Dubai 2024

uh yeah if you're expecting uh R pal sorry you got me uh R's uh flight got canceled well done for getting here uh it was a bit of a mission for me but I am uh I'm very grateful uh to be able to come here and uh and and speak to you um yes if you don't know uh yeah my name is Gavin uh I've uh I've been in this industry about uh 10 on a half years more or less um and I'm uh reasonably well known as the co-founder of ethereum and uh founder of polka dot um ah Jam Jam is what I've come here to uh to tell you a bit about I'm not going to go too deep into the technicals I know that um you know maybe actually I'm I'm kind of wondering can I get a show of hands for people that have have written like a line of code and compiled the program knowingly okay so maybe a half two two3 and um uh hands up if you know of the yellow paper the ethereum yellow paper okay like maybe a third so it turns out that a yellow paper which uh I wrote the uh uh the first version of um is uh it was first published almost exactly 10 years ago uh to this day um it was actually 10 years ago on Tuesday today's Thursday but very close um and one of the things that I really want to uh uh get across is um that I've been working on something very similar uh uh in in uh in Direction uh to the yellow paper but I think a little bit more um technologically advanced but I'm going to get to that in a second for now Jam so jam is a uh rollup reactor right basically it's a uh a new design of blockchain that's uh uh is very much designed around bringing rollups together hosting rollups and then combining them in a succinct model in a really effective model so it's got secure audited rollups these are a kind of rollup that we've developed uh we developed them for polka dot um but uh in reality they're very much like uh other rollups if you've heard of rollups um basically uh a way of getting through a lot more um data and a lot more uh computation uh without bogging down everyone that's uh uh running through the main uh blockchain now it comes with high resilience data availability quite a lot of it and we've developed a new virtual machine so if you're familiar with the evm we've developed a new virtual machine called pvm now polka dot was originally well is based around web assembly um a protocol that's uh well a machine spec that's quite uh uh made for like the the the web browser uh we've kind of thrown that out and started a fresh based basing it actually on the risk five architecture which has gotten a bit of uh uh Fame recently with with some of the other projects uh that have also been using risk 5 and uh pvm is basically a a sort of um alteration of risk 5 that makes it um inherently very uh recompile to x86 code um we've also managed to get metering in there which is really helpful if you're trying to do anything in consensus um and because it's risk five a risk five derivative it's very easy there's already a lot of tooling right llvm uh already works with this and it brings with it I don't know dozens of of languages that you can Target at um at now pvm now the key thing to understand about Jam is it's transaction doesn't have any transactions that make their way directly onto the jam chain rather it has this thing called agile core time it's a a concept that we've been pioneering uh that's been pioneered in polka dot but basically you buy um chunks of blockchain of of of of of block space if you like at a time significant amounts of block space I'll get on to the numbers in a second um so the jam data topology looks a bit like this it looks like a series of of flowers if you like each flower is like a slice in time or a block um now the interesting thing is that down the middle of the flower runs the this kind of like uh uh the center of the flower right like where all the petals lead into right um the bit that the the bees uh uh jump fly in and try and you know pollinate whatever um this is like very similar to what normal block chains are they're basically like just a series of of progressions of a of a of state right and normally the transactions go straight into this the center in fact with Jam the transactions go or the data coming from the external World goes via the petals the petals represent the blockchain equivalent of supercomputers right they they go very very fast they can process a lot of data they can get through a lot of computation now the cool thing is that the petals don't necessarily map one to one on each other like in um in designs like polka dot and some of the uh for example in ethereum some of the uh ZK the rollup um uh uh proposals instead the petals are just general stateless machines they can do basically anything and they can change what they're doing and the data that they're working on from time slice to time slice so let's have a look at one of these cores pull one of the petals out and see what it looks like so here is uh the anatomy of a of a jam um core one of these petals it's a bit of a misnomer because of course you expect the core to be the middle maybe there's a name change uh uh in the uh in the future of this I'm not sure but anyway the the core itself so this petal can process really quite a lot of data 2 and a half megabytes in is what we're targeting 2 and a half megabytes out can take any data that's already been processed by other cores in the past do stuff with it and then leave it for further future CES um to work with um it it's got a limit you know the past it only stores a month worth of data is what we're targeting um and therefore uh if you're leaving data for other uh uh uh uh times to process then it will only be around for a month now it can also send some information into the middle of the flower right less because of course all of these petals can't send all of their information into the middle or we' have a scalability issue they can send about 15 kilobytes a second into the middle which can then integrate it with all of the other stuff that all the other petals have been doing and uh fold it into the the machine state right the single state machine so we have this um what I call a semicoherent model right it's not fully coherent like you would get if it's just a single state environment where everything can interact with everything else all of the time but it's also not a persistently fragmented model like you would get if you just have different separate blockchains that are bridged with each other or models like polka dot and uh ZK rolled up ethereum where you've got totally different chains that maintain their own State and can occasionally kind of send messages into the middle our current performance targets that we're looking for Jam are uh two petabytes a little over uh for uh high high resilience distributed availability right so that's the total amount of data that it's going to be able to basically uh store at any given time now the amount of um the amount of data per second the amount of sort of input and output that it can do is 850 megabytes uh and then it keeps that 850 megabytes around for 28 days now per in terms of incore computation um estimations are really hard to make because the pvm architecture is totally different to the evm architecture it's much more in line with the the x86 with real Hardware architectures um but in our admittedly pretty uh pretty uh uh uh uh crude uh uh estimations um we are conservatively so at the lower end estimating around 150 billion uh gas per second right across all of the cores in terms of the coherence bandwidth which is basically the data that makes it from the cores into the into the middle that's about um 5 megabytes a second which gives uh once you get it into the middle you can do about 250 million evm uh equivalent is uh gas per second now these numbers are probably going to get updated as we do more tests get real empirical results but back at the envelope these are the sorts of numbers that we're looking at now the thing I really want to discuss today is the approach um that we're taking with building out Jam um it's rather a different approach to how we've uh what we've done with polka dot and it's centered around um the desire to really decentralize and create a decentralized protocol um it's very easy to fall into a sort of very Central even if you even if your network is decentralized even if you have lots of different validators all sort of validating and not all networks do by a long shot um it's not always so easy to have a decentralized protocol right decentralizing a protocol implies that expertise on the protocol is also decentralized that it's not just contained within one group or one company so in pursuit of this um there are a few uh initiatives that jam is is bringing uh one of them is the gray paper so the gray paper um in fact uh here it is the jam gray paper um it can be seen as uh a followup uh in some regards to uh the yellow paper in that it's uh it draws upon many of the concepts in the yellow paper there is um uh many references to the yellow paper and it's in a similar format to the yellow paper with a similar um uh a similar uh uh desire to have a formal um pure mathematical specification of the protocol not one that's defined in terms of an implementation that comes with all of the opinionation about the implementer and all of the opinionation about the language that it's implemented in no this is a pure mathematical specification for the jam protocol it's taken me about um six or seven months to write it um it's not really finished I expect the for the coming months for the paper to evolve much as after the yellow paper was initially published April 16th I think 2014 um the etherum protocol wasn't properly sort of finalized really um until uh I think around December that year so I I expect a kind of Fairly similar schedule for the gray paper um the point of having a formal specification is to underline the fact that jam is a protocol it's not a piece of software it's very easy to accidentally to think you're designing a protocol but accidentally create software where the protocol is secondary to the software where the protocol is really defined by what this piece of software does and that's problematic because it means that you're going to have centralized expertise and that's not what we want for a decentral it's not what we need indeed for a decentralized protocol if you want to see more about the great paper go to gray paper.com um I'll be doing a series of uh tours around universities uh to basically uh describe and try and uh uh teach how to interpret the gray paper I'm well aware that the gray paper is not the easiest thing to read it's not exactly a you know a light bedtime story but it's uh it nonetheless it is comprehensible by by people with a reasonable technical background and I want to make sure that the uh the teach M the teaching material is there if you want to learn exactly how this protocol Works um I'll put the dates and places on the gray Paper website if you are interested in coming to one of them um now in addition to the gray paper which spec which basically gives this definition of correctness um there is also the jam prize now the jam prize um is uh it's a fund that uh is is uh underwritten by the web3 foundation um and basically it's there to try to incentivize um a wide range of individuals and teams to implement the jam protocol in whatever way they they they choose um indeed we want ideally as many different kinds of implementation as possible like we want many different languages to be implemented and proba probably many different levels of the protocol to be implemented so basically we we we have um an idea of having four um uh implementation tiers and four sets of implementation languages and the prize would be distributed to um individuals or teams that are able to uh uh implement the jam protocol and pass the various conformance and performance tests um uh and uh uh to the the tier that they to to some particular tier so the sorts of things although it's not finalized the sorts of things we're thinking about are things like hey you're at the tier where you can synchronize the chain you can't build blocks uh and you can't keep up with a chain necessarily but you can at least synchronize with it um maybe there's a tier above that where you can not only synchronize with the chain but you can also valid you can be a validator you can you can contribute to the extension of the chain and then above that maybe there's a tier where you can actually synchronize and keep up and validate on the the final polka dot Jam chain um details will be uh will be uh coming soon probably over the course uh of the next month or so one of the um things that was difficult When developing polka dot the polka dot protocol was understanding why some things were not going as fast as we expected them to or were broken um when when a node individually appears to act correctly but combination of nodes seem to uh uh act incorrectly or not as we as we would expect the emergent effect so to speak uh became becomes uh sometimes problematic analyzing that is very difficult um so one of the things that we are uh sort of rethinking in that regard is how we get around this uh period of optimization and uh and trialing and testing and in this uh uh there's therefore an initiative that was starting the jam toaster which is basically a fullscale replica of the Final Jam Network th23 nodes which is what the jam network is designed to work with um each going at more or less full speed um where you can introspect deeply in exactly what has happened in the network um we've got you know high quality logging etc etc etc and the idea is that any implementation team that gets Beyond a certain level um where where their implementation actually works um is welcome to utilize the jam toaster to help optimize and debug their implementation in uh the idea that the Final Jam Network goes as uh uh uh fast and optimal optimally as possible if you want some numbers got about 16 a half thousand AMD thread thread Ripper cores in there 16 gigs just in L2 cache uh 32 terabyt of RAM and uh uh a lot of storage and some pretty hefty uh network uh networking infrastructure all right so how does Jam become a thing well the first thing to note is that the title of the talk was a bit presumptuous um uh it's not a it's not a given that jam is what polka dot uh uh could uh would will become it's merely I think a front runner in a proposal proposition for polka dot so the first thing is to publish the gray paper the specification of jam um which has just been done as it happens um the second thing is to uh uh is to ratify the general approach and the SC that the gray paper proposes and this is something that should be happening more or less now um a governance proposal will be put forward by the web3 foundation um and I'll go into that proposal in the next slide once the ratification happens then the web 3 foundation will be in a place to um activate the implementation prize this gray paper prize probably several months of protocol optimization parameterization and evolution will happen as I mentioned before but hopefully uh if if uh ethereum is anything to go by then at the end of the year should see a reasonably final um uh uh protocol proposal uh protocol spec of the jam protocol at that point I'd expect to see a final ratification then finalization of validator implementations and uh a migration from the relay chain to the jam chain so we have at the moment the polka dot relay chain perhaps in the future if everything goes to plan there will be a polka dot Jam chain so let's have a look at the governance proposal uh for those of you that don't know polka dot is a pretty uh heavily decentralized Network in particular uh over how it is run and funded um we put a lot of effort into deifying uh the protocol indeed um I think it's essentially the biggest functioning Dow uh out there um the scope and direction of the jam as specified in the gray paper describe a protocol which should replace the relay chain right so that's the first point of The Proposal um and then basically the next three points are to bestow responsibility onto the polka dot Fellowship which is basically the technical Minds behind the polka dot protocol and implementations and they would be responsible for ratifying the Final Jam specification uh they'd be responsible for the development of all of the tooling and various bits of software that are required to be able to turn the polka dot relay chain into the polka dot Jam chain and they would be responsible for determining when it's ready to go and then at that point halting the relay chain starting the jam chain with everything migrated over from the relay chain to the jam chain and finally the Readiness so these guys that the polka dot Fellowship should not consider it ready until there is a successful independent audit of the protocol itself and uh three implementations that are viable that can keep up with a network and produce blocks correctly um that are themselves audited um this approach is quite a lot different to the approach we have for polka dot which was get it out as fast as possible with Jam we really want to take the time and build and prepare to ensure that when it starts it is resilient it is decentralized good um I've said everything I've come here to say was actually given a 20 minutes slot and they they kind of gave me half an hour so I'm a little bit early um but do feel free uh to to use the time to get a cup of tea thank you