Protocol Berg Keynote: Gavin Wood - Agile Coretime
ETHBerlin·Mon, Oct 9, 2023, 12:00 AM
Speaker
The "Polkadot Ubiquitous Computer" (or just Polkadot UC), represents the public service provided by the Polkadot Network: it is a trust-free, WebAssembly-based, multicore, internet-native omnipresent virtual machine which is highly resilient to interference and corruption. The present system of allocating resources of the Polkadot Ubiquitous Computer (parachain slot auctions) is based on a model of one-core-per-parachain: this is a legacy interpretation of the Polkadot platform and is not a reflection of its present capabilities. With Polkadot's capability to adapt to its users'need, a new paradign for allocating coretime is being implemented by ecosystem teams. Coretime on the Polkadot UC is envisioned to be sold by the Polkadot System in two separate formats: Bulk Coretime and Instantaneous Coretime. When a Polkadot Core is utilized, we say it is dedicated to a "Task" rather than a "parachain". The Task to which a Core is dedicated may change at every Relay-chain block and while one predominant type of Task is to secure a Cumulus-based blockchain (i.e. a parachain), other types of Tasks are envisioned. Bulk Coretime is sold periodically on a specialised system chain known as the "Coretime-chain" and allocated in advance of its usage, whereas Instantaneous Coretime is sold on the Relay-chain immediately prior to usage on a block-by-block basis. Gavin Wood https://protocol.berlin
Transcript
foreign our first edition uh super happy to see everybody's faces here I'm Helena your host for the next few sessions I'm a core member of the dod I also work at scroll um some of you may know that I started my journey at parity Tech so it's a great honor to introduce the next speaker Gammon wood co-founder of ethereum founder of polka dot here to talk about agile call time hello um yes where's the plug okay you actually get two talks today I only found out quite recently that it was I was on for 15 minutes so uh I hastily put together a sort of uh starter aperitif talk which shouldn't take too long but I think it's it's nice it points out a few things that that I think are quite fun to point out and uh oh dear all right this stays on and then uh and then I'll proceed to like the uh the the meat and potato uh talk am I on yes okay f right lovely to be back in Berlin everyone from uh are we all like uh living here or are people traveling from Far Far Away to come one two from where near fair enough um good so yeah this first talk is um oh you can see if you want to look at the slides there's an URL um this first talk is is sort of uh discussing uh some of the uh conversation points that have been um floating around uh in this industry uh of late um and uh particularly uh from the polka dot perspective um actually uh you know polka dots the sort of top level stuff uh then you know I don't know how familiar you are with this stuff but um polka dots more of us like a a wider Network um maybe an ecosystem um substrate is the uh a tech that we use to make blockchains that sort of slot in to polka dot and then within this blockchain framework we have a a a framework specifically for building the business logic of blockchains uh called frame and for what it's worth inside a frame there is also smart contract modules that allow you to have Smart contract systems what I'm going to talk about for now is frame so just bear in mind that frame is a piece of substrate which itself is a piece of polka dot and at each of these levels they are in principle replaceable all right so uh account abstraction a bit of a Hot Topic at the moment uh in some circles what do we mean by account well generally we mean identifier for a caller like a caller of a function some logic typically sitting inside of some um uh decentralized system and we usually use accounts to confer particular privileges for example the ability to spend some balance that's sitting in some account in principle accounts might be viewed as something that's quite homogeneous which means to say they all confer the same class of privilege but just a different specific parameter to it though that's not necessarily always always needs to be the case this is sort of based around the ethereum account model let's look at this within the polka dot perspective so we have the concept of an account based privilege level an account caller caller that we describe by a specific 32 byte in polka dots case identifier what we call a signed account origin now this is actually our type of a wider data structure called the system origin system origin is an origin that is amongst basically all substrate chains and certainly all frame chains all frame chains have this this kind of caller kind of privilege set in mind the system origin is actually a subtype of the runtime origin so the runtime origin is actually An extensible Origin kind system origin is one of those kinds of Origins that you can have but there are many others and in fact as I say it's extensible which means you can add your own you make a new module which we call a palette in frame language if you make a if you make your own module you can add your own kinds of Origins and obviously these kinds of Origins can confer certain privileges according to your particular use case now as it happens the runtime origin is is also um sort of ensconced in an even larger more richer origin type called the xcm origin and the xcm origin is very large and very rich and in principle um the language that we use xcm is really just a language um with this origin you can describe we one would hope um pretty much any caller privilege class on any um decentralized system so Q video um I think this is aspiring program we turn it similar to the programmed reality of the Matrix it has the same basic rules rules like gravity what you must learn is that these rules are no different than the rules of a computer system some of them can be bent others can be broken that's an excerpt from a uh a notable film first practice in Singapore and there was a Scarlet tin that's an excerpt from a notable film called The Matrix um uh great film uh what your man here is talking about is trying to explain to this young pad one um that in fact what he believed was the real world that had all of these very uh particular um rules that could not be broken um is in fact merely a simulation and he had some god-like privileges within this simulation which if you were only to wake up um he could realize and alter some of these fundamental rules um he mentions bending some and breaking others as far as I know he only ever really broke them but uh yes in polka dot we have a similar um kind of situation um whereas Morpheus mentioned gravity as being a rule that could be broken if if only Neo understood in The Matrix well the account model in uh polka dot while it may look as though it's very similar to a hard-coded account model like the one in ethereum in fact it's much more like the Matrix situation and if only you learn the underlying frame language you will see that you can bend or even break many of the rules concerning the account system so let's go back to the origin example so if we remind origin in the polka dot World in a frame World specifically um helps us understand who is calling this piece of logic that is being called we would assume in a decentralized perhaps permissionless system well we've already mentioned the signed origin the signed origin tells us well this account this account assigned a transaction they're the ones who are calling it well there are other Origins one of them is the root origin which I can imagine uh many uh many are Unix user here can probably guess what it means the root origin confers all possible privileges to the code that this caller is attempting to have called no one can sign for the root origin that wouldn't make any sense at all would it like if you had a site well if you had a signature that could just alter anything on the Chain no although we do have a module called sudo that does allow you to confer the root privileges if you so choose this is useful for permissioned ledgers normally the root origin would be in origin that can be only called with the execution of some logic to ensure that it's in the blockchain's overall interest for example governance I have a bunch of other Origins here the treasury origin has the Privileges of being able to spend the treasury the collective members origin represents some proportion of members from a collective yeah this is still an end point this is still like a caller type but we're not being specific about who or which account is calling or we're saying is Well some collective exists maybe it's got 100 members and we know that maybe 80 of them um actually want this thing done and this allows us to build all sorts of very interesting sophisticated governance structures we use all we also have a a caller type parachain this means that a parachain wants this again this is impossible to really you know it doesn't really make sense to think of it in terms of an account um Power chain doesn't necessarily hold an account but it is nonetheless a logical means of calling some code person would be another one xcm would be another like a message that's arrived from some random locations somewhere and the um uh decentralized logic sphere all right let's look at specific non problems then transaction batching suppose we want to execute several transactions all up all at once all one after the other from a particular end point be it an account or something else well actually it turns out that this is really easy in frame in fact it's a very small little um transaction type called utility.batch and this is part of a module that anyone can add as I say our module is called pallets you can sort of upload um a uh a palette and agree that it should be part of a blockchain delegation again already implemented utility.proxy part of the same module as it happens uh multisig or threshold signatures well yeah surprise surprise this is already implemented account utility.ultysick um suppose we want to do account recovery on a lost secret key so you've lost your secret key the secret key represents some particular account right the hash of the public key whatever it is um but you uh you've lost it and you've set up some social recovery system but you would like to reclaim um not just any of the assets associated with it but like all of the Privileges right uh maybe I don't know I had some identity thing associated with it or I had some other um particular I don't know associations um and you need to be able to control the actual account well you can't obviously magic up the secret key um but in the frame framework that account can just be used uh can be can be um regained through a pretty trivial call um to this social recovery palette what else we got exotic signatures well in frame signatures are not really uh a fixed thing they're not hard-coded um there's actually just this interface called verify and currently we have three different signature types and if you wanted to add another maybe something that is resistant to new forms of uh of Technology then it's possible to um just Slaughter in now suppose we want to do that but we don't necessarily want to alter the underlying blockchain sort of system it's also doable from within a module itself using signed extension now signed extension is something that allows us to alter the transaction format in a modular manner in a very extensible manner and in fact this was used when we needed to be able to allow individuals that had a sort of dot balance held by an eth account like a 20 byte ethereum address um and we wanted them to be able to claim these dot balance within polka dot which obviously doesn't sort of understand what's going on in the in the if World um and it was it was pretty trivial in the end um using these uh these cunning extensions it didn't matter in particular that they didn't already hold dots and that they didn't have to make their account exist and that they didn't have any dots to pay for any transaction fee suppose you want to pay fees in a non-native token another sort of hot topic well in frame paying fees isn't part of the protocol it's it's actually an extension itself there is something called the transaction fee module trying to actually V pallet is a palette that you can sort of slide in to your chain if you so want and one of the things that it allows you to do is to configure whether fees should be paid as part of a transaction they don't have to be so if you want to pay fees in some other way or have some other anti-spam mechanism for your chain it's pretty trivial um paying someone else's fee little more uh well okay a little more involved practically speaking as far as the on-chain part goes it's pretty trivial but of course getting uh transmitting the thing that you want someone else to pay for um is is a little bit harder you need some sort of off-chain message passing kind of Gossip system which is is not especially uh uh easy to um come up with but nonetheless once that is done the actual on-chain bit of of ensuring that you can actually pay for someone else's transaction easy easy peasy what about uh accounts always needing a balance for gas fees well again as I mentioned earlier signed extension really easy now actually frame has an even easier way of doing this if you just want to make sure that they don't have to pay for some transactions under certain circumstances you can it's as easy as returning pays no from the transaction code and just means the system picks up the tab so yeah um there's a lot of um a lot of stuff that you can do if you free yourself for your mind from the uh from the idea that the the account model is sacred and can never be can never be altered under any circumstances and systems like frame allow this to happen in an incredibly easy uh and uh and uh modular manner okay good this is uh this is the first little thing I wanted to cover and as far as I know I'm 20 minutes in all right I'll have to hurry up a little bit then right agile core time now I presented the the beginnings of this uh back um polka dot decoded um two two months ago or so um it's it's a bit of a it's an interesting sort of um mental Journey first Stay With Me what is polka dot what is polka dot one right well if you go back to the uh white paper polka dot it says is a scalable heterogeneous multi-chain blockchain of blockchains right that's how we Define polkadot that's what we aimed to build with polka dot and that largely is what has been what is out there now called polka dot um so here is my uh back of the napkin drawing of that there's the relay chain in the middle and there's these little you know chains on the outside they're the power chains for those who are not familiar with polka dot terminology but they're just block chains right they're blockchains and The crucial thing is that these blockchains get all of their work checked by polka dot and as such share their security guarantees with polka dot now if let's dig a bit deeper because that that's all very well but it doesn't really explain to us um what we have done to achieve this goal well the first thing that polka dot does is it procures certain information technology and communication should be a c in there really resources from the public now we call these uh resource providers validators and they do particular jobs for the polkadot Network in general they just run a particular particular piece of code that does the right thing um there are certain resource requirements that these validators these members of the public must provide in order to make things work and get paid basically now given that polkadot is able to procure these resources from the public validators it then provides an environment a platform to resiliently ensure that these little blockchains the ones on the outside and state machines that seem like them so there's a certain class of machines that it can do this for but they're generally blockchains or blockchain like things that they progress properly right that that that's when they then they get to the next block and they say well this happened um that that this is is is that they they're saying happened actually did really happen and was a legitimate um event or a legitimate um uh course of action so how does it do it well it uses cryptography in part and a lot of economic quite sophisticated economic games um to guarantee this right to check that these progressions of the little ones the little chains um a right a correct and it it verifies what they're doing so basically replays all of this logic and it Chronicles it it records it um so that in case there is a dispute later on um we can go back and we can check the working again um now we've got a lot of logic it turns out turning these 1000 members of the public volunteers almost I mean they get rewarded but they are volunteering to get rewarded um into this particular resource for verifying and chronicling this computation and there is a bit of a bit of logic dedicated to um doing making um making the environment right to ensure that this secure reliable and accurate resource actually works for blockchain things rather than maybe other things so we've been very um we're basically optimized the situation um for blockchains for for checking blockchains this was the whole idea with polka dot one right but as a byproduct it turns out polka dot has these logical virtual machines that kind of are spread around the globe different randomly selected validator sets hosting them and it uses these logical units these these virtual machines decentralized virtual machines um at the moment to secure blockchains to secure para chains to secure the blockchains of the polka dot ecosystem checking their correctness chronicling what's happening they didn't do that necessarily they could do all sorts of things these cores yeah they are at the end of the day basically just virtual machines that are guaranteed to operate correctly so in fact what we've inadvertently created with polka dot one um isn't uh the overarching multi-chain network or that's one of the things that we've created but the inadvertent thing that we've created is actually just High resilience validated computation so if we look at polka dot as a ubiquitous multi-core computer well we can start describing what this computer does like we can describe its parameters what is this virtual machine capable of well it turns out that we can have potentially hundreds of these little units all operating in parallel these cores and the core bandwidth it turns out is about a megabyte a second so it can do a megabyte a second of I O with the rest of the world and if you want to get an idea for how much computation it can process well it turns out it's got a geekbench 5 SC single threaded score of about 380. and it takes about six seconds if you want to get things in and out and overall we would expect this to track Hardware so as Hardware gets better these numbers will go up now as I said this core resource we've kind of limited it to to a particular model of computation which we might call the power chain model it's it's very optimized for blockchain like systems because you know that was the whole that whole point of creating this that was the use case um and the parichay model extends to how the resources procured it's procured through long-term leasing auctions deposits crowd loans but it doesn't necessarily need to be this way we may yet be able to expose these same underlying resources this high quality resilient multi-core compute uh units in a more General way why why would you bother doing it sounds like work well two reasons first economic efficiency we've got this resource and it's a pretty decent resource and we're currently taking the resource and just baking it into one particular service one particular product it's kind of like we've got we've got like I don't know a big farm and we're producing our own flower and seeds and water and stuff and uh we're taking this flour and seeds and water and yeast and whatnot and we're baking it into one specific type of bread when in fact there is the whole world of French pastry that we're completely missing um if we always bake it into one particular kind of bread and it turns out that this particular kind of bread isn't uh exactly what everybody wants um then there is economic inefficiency we are also motivated by technological flexibility the ability to prototype new things with this decentralized resilient compute resource we want to open up the design space ideally beyond the core development team into the hands of everybody because ultimately every particular usage of this resource implies some design decisions implies opinionation and as soon as you're opinionated you kind of block off a lot of the potential well a lot of the potential so rather than fixing this opinionated design decisions let's try and wind it back just provide the underlying resource in as pure reform as possible so this is where agile core time comes in and agile we mean two different kinds of agile we mean agile procurement and we also mean agile utilization at the moment procurement is not agile it's very heavily centered around long-term usage of one particular core and utilization isn't very agile either it's a bit better I would say but it's still not super agile it's still optimized for utilizing a core for a particular compute Machinery in this case blockchains or verification of blockchain specifically all right so let's talk about procurement cores are agile procurement should be agile as well um so we have two polka dot native sales for core time by which we mean time on a core of the polka dot multi core computer bulk sales which is basically four weeks of core time sold at a time so these kind of like big chunks of core time not that big monthly which is a lot less than what we're doing currently which is two two yearly um and instantaneous core time now this this sort of um short circuit um a lot of the the monthly this bulk core time logic and goes directly into the relay chain says actually I motor block right now here's the work I'm I'm over the core right now I should say so it's like a book sales four weekly sale so we do a monthly sale of a month-long amount of call time we do it just sort of I don't know a few weeks before the core time is due to begin we target some amount of cause that we want to sell if we sell fewer than them then we can we can basically adapt the price price goes down if we sell more price goes up um an unrented cause go into the instantaneous Market for use on an immediate level special considerations for pre-existing tenants block parachains compare that to instantaneous sales so this is a blockly by which I mean every block sale of bulk core time so there's a price and this sort of moves up and down according to demand um and basically you're able to purchase bulk core time at uh you know one or two blocks before you're gonna actually utilize it um as I mentioned there's a automatic Market maker to regulate the price targeting that all of or 100 usage so if there's plenty of Supply this price is going to be pretty low and the idea is that if you've got some spare bulk core time you can put it in the market and kind of sell it through this mechanism and then the total sale will be uh [Music] will be split between the core time providers now bought core time is a pretty interesting thing and it may be the first legitimate usage of an nft um now the idea is that the call time service exposes um through xcm and xcm as a sort of nft interface um exposes these tokens um they're non-fungible they represent some particular claim on a polka dot multi-core computer on one of the cores and in fact it's not just like on one of the cores sometime it's like on one of the cores between Timex until time y at regularity are like frequency if you like one in every two blocks every every block one in every ten blocks this kind of thing now when you buy bulk core time you get an nft that basically says well it's it's on this core it's four weeks it starts on this this time ends four weeks later and it's every block but maybe that doesn't fit your use case maybe your use case you don't actually need to use the core one in every four blocks um for the first week of the month and then one in every two blocks for the other three weeks of the month well this allows you to do that or indeed any any random parameterization of that um so you're able to split these nfts up and make from one nft that represents four weeks to two nfts that represent I don't know one week and three weeks or one day and 27 days or whatever it is that you want to do you can also take these nfts and split them up further you can do it as many times as you want and even cooler you can take nfts and de-interlace them like pull them apart so you can make them two nfts of each irregularity that sums to the original nft yeah so you can take for example an nft that does it every uh uh two blocks from for some period and turn it into two nfts each that do it every four blocks yep and then you can put them in a market it's just an nft like any other nft so you can auction them off you can sell them trade them whatever I mean I don't know what stuff's out there for nfts but I presume it's like pretty sophisticated by now so they can be moved between chains and treated basically like any other nfts anyone can even imagine markets that sort of even reduce the non-fungibility of them basically saying yeah sure if you want if you want to buy something that's kind of roughly from this time to that time at roughly this regularity there are these nfts that are for sale at the moment yeah foreign bulk core time in two different ways as I mentioned before you can put it on the instantaneous market and take a cut of the profit you can also assign it directly for utilization utilizing it may be for example dedicating it to some particular power chain but there could be other uses so let's keeping that in mind move on to agile core times utilization now this is uh very much an ongoing discussion so I'm not going to try and present anything as being kind of decided or anything like that I think with the core time or the procurement this is already coded and scheduled for um for deployment onto the Pokemon network with utilization still working through things through overall tenants in my mind are firstly to minimize changes I'm going to use what we've got as much as we can and secondly to maximize potential and Empower potential I would say is permissionlessness try and like ensure that as many people can utilize and rebake this Resource as possible foreign so let's look at some of the ideas that we have for utilizing agile core time so the first one is the polka dot one model parachain model I have three others well two two-ish two or three others that I want to talk about um at the moment one of them is the actor model another one is the map reduce model and I'll talk a little bit about some more sophisticated models that are also under discussion so just to be clear this is alternate means of utilizing the underlying resource this compute machinery that polkadot provides one of them at the moment is to check the progression of blockchains power chains but there can be others so let's look at the parichay model what does it mean well for those who are not familiar on polka dot every parachain has a code blob associated with it it's actually a piece of webassembly when a power chain wants to move forward and and make sure that it's uh that it's verified through the polka dot Network it submits a piece of data to the polka dot Network we call this piece of data the proof of validity and POV every parachain has a code blob known as the parachain validation function as you can imagine this validates a transition that a parachain does every proof of validity basically a document that gets sent to the polka dot validators describes well it references one specific parachain and it describes how it has moved forward providing any necessary data that it might need as a validator of the program Network to do it to check it's working witness data these um this power chain validation function this code blob has a fixed entry point it's called the execute block um and it's just one of them that gets used just this execute block so the proof of validity this document basically gets fed in to this entry point in the code blob power chain validation function and it gets checked to make sure it's correct there is also some hard-coded logic that sits on the relay chain this is out so this is like done sort of after these proofabilities have been checked and it sort of manages any of the message passing so this in a nutshell apologies for the uh uh jargon but you know it's quite complicated and I'm trying to boil it down um this in a nutshell is what polka dot is doing how it's utilizing these cores in order to create this parachain um uh uh Centric model where you can have multiple blockchains all operating under the same security umbrella foreign actor model which I am calling core play well we have one code blob per actor so a bit similar to how we have one code blob per parachain that bit doesn't really change however we can have multiple actors per V proof of validity and at this point maybe it's not so sensible to call it a proofability maybe we can just talk about it as a work package right some document that gets sent to the polka dot validators hey check this validate this work package well we can reference multiple actors in in these work packages now the work packages the povs they have a manifest and this allows us to specify which actors um get sort of entered get their code executed when in what order so this is quite a lot more um quite a lot more of a sophisticated compute model and we can have multiple actors per POV multiple entry points into those actors as it happens there's only really two one of the entry points is to progress the actor do more compute have some more time on the on the polka dot um computer and another one is uh do some IO here's some input give me some output so it's actually only two entry points but still more than one and that has upwards message passing which is one of the message passing protocols one to take it up to the relay chain this is hard-coded okay so this is the optimal and with the actor model we can do some pretty interesting stuff because we can have multiple actors per work package and because then we know that they execute on the same core and because we have a manifest that allows us to kind of switch between them do some work in one do some work in another do a bit of iom on do a bit of IO in another um we can do some very interesting composability we can have actors that kind of speak to each other and then the next block reconfigure themselves and do something else more on that in a second before before I do that uh go into a little bit more I want to talk about the map reduce model so matte reduce is a um pretty General Paradigm for uh in particular uh representing a kind of workload that can scale well on uh on a homogeneous um uh um uh parallelized compute system somewhat similar to what polka dot turns out to be um this one is kind of project forecast so it's a mapreduce model for utilizing or for expressing the kind of computation that we want done on this polka dot multi-core computer so map and reduce we have two different code blobs per work type so work types are a little bit like power chains or actors but instead of having one code blob we have two hmm well when a work package comes in what we used to call a POV work package now it names a particular work type the map code blob each of these code blobs only have one entry point the map code blob is applied off chain this is the thing that gets checked this is parallelized yeah yeah many different maps of the same work time all work type all happening in parallel or with different validated groups all on different polka dot cores whereas reduce is applied on chain synchronized pretty much as you would expect for those familiar with mapreduce the verified output submap so map has some smallish outputs and these are used as inputs to the reduce function and reduce can mutate some on-chain data robot um work type state tree specific to the work type turns out this is quite General we're also considering other more sophisticated models maybe arbitrary dependency graphs between the work packages asynchronous work package items potentially even unbalanced resource usage support for it using more for example availability i o bandwidth rather than compute or different kinds of compute GPU compute versus CPU compute very interesting stuff okay watch this space guess I've probably got five more minutes left so with five more minutes left I would like to can I full screen this full screen uh present all right I'd like to just go over core plane put something in your mind because this is like a little bit more um visual um kudos to our very own Iggy for helping me with this stuff this wasn't my fair hands I'm afraid this was a rather talented designer okay um so uh core play so this is a potential actor based model visualized for your viewing pleasure on polka dot in this case there are uh at the top there there is the audience this is a validator is that they're watching everything making sure that it's uh that it's proceeding correctly right we have our six stages now the stages are basically caused yeah core represents a stage there are six in this one because there's six sort of blobs on the polka dot logo but in principle there could be hundreds of these stages if I drew hundreds it would all you wouldn't see the forest for the trees so that's why there's only six characters sit on the stages I acting these are the active tasks right these are the things that are actually running at this particular Block in time backstage are all the non-active tasks um the non-active tasks uh well the actors are able to send messages uh between each other um uh through this sort of xcmp tile it's like Mail system so they have like I don't know uh pigeon holes you can imagine it as now let's get on to this the stage like because this is very uh a very interesting um uh uh model for compute so On Any Given stage if you remember a stage basically maps to a core in this actor model of using polka dot core play we have the backstage I ever lift the lift you have to lift and actor up onto the stage right this is kind of like IO it's a bit like IO right you have to get the actors code out and kind of get them get the code out and get ready to use the code so there's like a bit of resource cost for bringing an actor on the stage and this needs to be paid for on the stage as I said sort of one-to-one maps with a core and we have these actors the actors are sort of sitting on the stage and at any uh given time there is a spotlight so there's some some guy with a spotlight and it can go between the actors As It Shines on an actor the actor executes right so this is we're only single core so we can't we can't have multiple actors all saying and thinking at once so we have a spotlight to say which actor is actually acting executing but crucially the actors can talk to each other synchronously this allows us to do synchronous composition we can do all sorts of Rich Frameworks when we know that the actors are executing in the same um the same execution environment we know they're being executed by the same um CPUs in the same piece of time this in a uh in a nutshell is one of the ways that we can sort of see the underlying compute Machinery the underlying decentralized compute Machinery of polkadot being able to be used Beyond simply hosting uh or rather verifying uh blockchains and I suspect if we come uh if we are able to reframe um polka dots resources in a uh such that they could be used in a permissionless fashion we all this won't be the only thing that we see uh the only uh sort of uh means of utilizing uh polka dots uh underlying compute Machinery um Beyond verifying blockchains I suspect there will be quite a few others and with that my talk is at an end I hope you enjoyed it foreign
Automatic transcript — names and jargon may be misspelled.