our next speaker someone who is uh one of the earlier chain safe employees the absolutely amazing elizabeth banks who will be presenting gossamer a polka dot journey in go elizabeth uh why don't you go ahead and turn on your camera and microphone and join me on the main stage hey elizabeth how you doing today good how are you dustin i'm doing well we have a great audience here today so i'll leave it to you and have a enjoy cool sounds good um okay one second okay cool okay looks like you guys can see my window all righty okay so hello everyone so today i am going to be talking to you about gossamer so yeah um it's i'll just get right into it okay so yeah so hi just i'll introduce myself to start off so i'm elizabeth i'm a software engineer and tech lead at chainsafe um so i'm the tech lead on the gospel project i've been working at chainsafe for almost three years now in march it'll be three years um yeah and these are a few of the projects i've worked on in my time cool so i'm going to give a quick intro about polka dots so why um so first of all what is polka dot and why did we choose polka dot so polka dot is an interoperability protocol um first of all so its main goals are to have interoperability and shared security between various chains that execute um different state transitions so as you can kind of see in this diagram this is sort of a high level picture of the system so you have the relay chain in the middle and then the pair chains on the sides um yeah so another um goal of polka dot is to have forkless upgrades so to be able to update the the runtime of the chain without needing to um like fork or upgrade your node so this is in contrast to ethereum or some other networks where you have to fork the network to um to upgrade and if you would like more information on polka dot you can see the polkadot light paper in their documentation it's a good overview of everything cool so a little bit about gossamer so um so we got a grant from the web3 foundation last january in 2019 um to build the polka dot runtime environment and go as it was called at the time um so polkadot runtime environment has since been renamed to the polkadot host um they are same thing just renamed um yeah so ever since then i've been working on gossner which is the um polkadot host implementation in go so you're probably asking what's the polka dot host so it's a good question so you've probably heard of substrate um so substrate is the original implementation of a polka dot host so um the idea with the polka dot host is that it's a blockchain framework for building your own blockchain um in addition to that it's compatible with the polka dot network um so yeah so substrate is the framework and then polkadot is the actual protocol that the network runs that substrate has also been used to build on other polka dot networks like kusama and the the test nets so um gossamer provides the same functionality of substrate um or ideally it will very soon and but except it's implemented in go um instead of rust so yeah and if you would like more information on substrate there's a really good talk by gavin wood at the web3 summit 2018 called substrate a rustic vision for polka dot so i'd recommend watching that cool so um yeah i'm just gonna give a gossamer update so um our primary goal for gossamer at this point is interoperability with kusama and polkadot so we're getting very close in terms of compatibility so we've recently upgraded to the v0.8 runtime i'll explain a little bit more what this means in the following slides but essentially it means that the the api for the um runtime matches now um with the with other networks um and then our in parallel goal to that is to have poke.js support um for customers so this would allow users to easily interact with the node manage their accounts and submit extrinsics and respond to the network in general um and then we're also working on updating so in also related to interoperability is updating the the networking protocols that we can sync with casselman polkadot because it's recently been upgraded and then as well as just internally testing the gossamer nodes um so they can stay synced and continue to finalize under various conditions cool so yeah so a runtime so one of the most interesting and challenging parts i would say if gosner is the runtime um so the runtime is the state transition logic of the chain um so as you can kind of see from this little picture um the block represents um one um transition i suppose well the transition is yes so how a block is created is determined by the transition function um as well as what transactions are valid to be included in that block okay so yeah so the polka dot host is essentially everything around the runtime that allows it to become a blockchain um so everything except the actual runtime itself is the host so the things like networking the storage tree um databases um all that kind of stuff that's that's what the host is all the things that are used by all blockchains so um so what is the kind of design decision for building um the host in this way so like i said earlier the one of the reasons is so you can upgrade without forks so um this allows for on-chain governance so you can um submit votes to the network to upgrade the actual state transition of the chain itself um yeah so yeah so the runtime is just a binary that's stored in the storage tree so it can easily be changed at any time and as well the other design decision is to have a standard interface for um the runtime so that people can easily implement their own custom chain so yeah so so yeah like i said earlier the wasm um yeah so runtime is just a web assembly or wasn't blob that's executed via some interpreter that's in the host um so it's sandbox from the rest of the code um yeah and then it doesn't store any node data it just has it just deals only with the state transition logic it doesn't store anything like um the storage um keys anything that else it needs it gets that from the host which i'll explain a little bit more in the following slides so gossamer currently has support for two different awesome interpreters um wazimer sorry the slide isn't great but but wasmer and wazomtime um so why so these two perform the same functionality which is interpreting blossom code um so currently it has support for both because we want to eventually benchmark the two of them see which one's more efficient as well as um determining eventually which is more maintainable for us which has an easier go api to use so yeah so using gossamer so um so if you would like to make your own gossamer chain what do you have to do so the main thing is putting in your runtime so if you look here in the genesis file um there's a section of the genesis file called system code and this is um where the runtime code at genesis is stored so so when you launch your train it launches the chain with whatever code is stored in this system code key so if you want to make your own custom chain you need to have your own custom run time first of all um it has to be compiled to a and then once you've done that you can simply throw it into this genesis field system code and then hit run and everything should work yeah as long as the api matches so what is this api i've been talking about um so from the go side of things the runtime consists of specific api functions so the runtime needs to expose these functions um so that the host can call into them so um this interface here that you see is the interface that customer uses to interact with the runtime so the functionality of the runtime is to do with block production as well as block and transaction validation so um and then there's also a few functions for configurations that have some constants stored in them so yeah so the first four functions here are to do with sorry to do with configuration options um and then the one after that validate transaction is for validating incoming transactions um before you include in a block and then the next four functions from initialize block to finalize block are used to actually build a block and then the last one execute block is used to verify a block that you've received from someone else so at specific points in gossamer's execution it'll call into these functions whatever it needs so yeah that's essentially the api so as long as the runtime matches these functions it matches api exposes these functions it is good to go cool so what's kind of inside the runtime so so um so a runtime you can build it either yourself in whatever language that can compile to wasm um you just have to implement the api that i showed in the previous slide um or you could use frame um framework for runtime aggregation of modulized entities so this is um a domain-specific language for building runtimes also written by parity and it's written using rust and can be compiled to awesome so um so the runtime is if you use frame it's composed of modules um called pallets that have specific functionality that you potentially would like in your chain um so a lot of them are just common um thing common sort of function features that you would like in a chain so like value transfers um like tokens props um there's also stuff to do with smart contracting evm support and there's also stuff to do with consensus so babe and grandpa um as well as on-chain governance so you have staking um which is super super important um as well as other governance things like i see treasury elections democracy that kind of thing so the idea with pals is that it's easy to just plug these in to your runtime just like pick and choose what you need as well as if you want to make your own custom palette you can easily do that as well yeah but then you wouldn't have to worry about the more basic things like value transfers and just plug those in cool and then also i don't know if you guys can really see from this picture but there's a support library that easily turns the modules into the api so cool okay so what does gossmer look like from the runtime so while the runtime is executing um it's able to access certain go functionality that it needs um via some functions that are imported into the the runtime instance so the reason for this is because the like i said earlier the runtime is just a binary that just has the state transition logic it doesn't have anything stored in it um so to do so it has to access the storage tree which is located um in the host so to do this the functions that are imported into um sorry the functions that are imported into the runtime instance can all access this context struck so the context contains um an interface for the storage as well as allocator for managing memory the key store for signing and then a few other um the rest are mainly just constants for letting the runtime know what the state of the node is um so the storage is the main one that's used so the runtime is um essentially the only part of the host that modifies the storage tree so while it's doing some um either block building or syncing a block from someone else it'll be updating the storage tree to update whatever values are needed as well as get whatever values are needed um delete any values um yeah so the runtime essentially does all the storage tree management for you and then yeah and then the storage tree is just a modified merkle partition tree um similar to ethereum so not exactly the same but similar idea cool okay so yeah so why is all of this interesting so this makes the runtime really modular so essentially as long as the api stays the same the runtime can change as much as it wants without any changes to the node um so yeah so like i said earlier this lets you have governance um upgrades without forking um that kind of thing so um yeah so gossler runtime updates mostly consist of updating the host to work with a newer api so generally when the api changes the core functionality stays the same the main changes are maybe a few new new functions or renamed functions or different parameters like that kind of thing as well as the imported go functions might be potentially different cool okay so what are kind of the next steps for gossiper so um like i said earlier one of them is polka js support to allow for easy user interactions and then kind of alongside that we'd like to build a go extrinsic library to allow for extrinsics to easily be formed and submitted on the go side um because right now all the tooling is in rust or javascript um and then as well since we have updated the runtime um we would like to try syncing with the different networks so the main ones would be polka dot and kusama and then also just a local substrate node um just to make sure that everything works with that um so yeah so the main kind of blockers here are just the networking protocols um so stuff like message encoding potential like the stream protocols that kind of thing yeah and then another next step is to just run a gossamer only test net um this can kind of be done in parallel with the interoperability stuff so this is kind of just to test that this functionality is consistent within customer nodes so um so make yesterday to make sure that um finality continues to to work um the network doesn't fork um changes to the um the epochs and the authorities the runtime and such are propagated um correctly and then as well to test under various network conditions make sure all that stuff still works um so yes at the gossamer testnet stage essentially users should be able to play around with the node um join the test net hopefully um yeah and then as well as at that point they'd be able to try their own gossamer chains so if you have um perhaps an existing runtime or you want to make one um you can try to plug that into gossner and see what happens cool okay so that's essentially it so thanks for watching if you would like to check out the code you can check it out on the chainsafe github we also have some docs up at gossamer.chainsafe.io and you can also contact me if you'd like at my email elizabeth chainsafe.io or um you can also message in the discord which is in the gossamer readme cool okay thank you and then hiring slide because we're hiring cool awesome thank you so much elizabeth i'm beyond excited for the future gosmer and the poco polka dot ecosystem very exciting stuff we do have a couple uh questions for you um and just to let everyone know there is a q a section feel free to put your questions there upvote on particular questions you want answered in priority and so forth so the the top q a question for elizabeth what has been the hardest aspect of testing runtimes great question okay so um i'd say the main thing is just the fact that the runtime is opaque um like it's just a wasm binary you don't really know like what's going on in it um so when you're um yeah so when you're executing the runtime you can't really see what's going on internally you can only see when it's calling into go functions that's like but then between that you don't know what's happening so sometimes if you have like potentially wrong encoding or some wrong um data it's really hard to know like what is wrong about it um and like how it's internally calculating and decoding it um yeah like sometimes um sometimes you can try looking at the rest code to see what it's doing but um like i said earlier it's written with frame for the most part um so then there's a lot of like layers that sort of wrap it so even when you're looking at the substrate code it'll say like oh it calls like system whatever key it wants and then um but then in when it gets compiled to awesome that completely changes and it turns into various other operations so it's hard to know exactly what it's doing so it's mostly yeah so i'd say the hardest aspect is um yeah just like getting the the data the data to encode properly getting it all to decode properly inside the the wasn't binary that kind of thing awesome thank you so much our next top question does this mean i won't need to know rust to work with substrate um correct yes so yes but you won't need to no rust so gossamer yes pure go um everything's go um yeah so i guess the only rust you would need to know um it's not even so much rust but just to build your own um runtime you would need to use something that would compile to awesome which is frame at this which is yeah so probably frame which is rust ask so yeah but you wouldn't yeah you wouldn't need to know rust to work with with substrate blockchains awesome thank you so much um another question what has been the most challenging aspect to building gossamer um okay another great question um yeah so the runtime has been definitely one of the most challenging um just because yeah like i said it's super opaque um as well as there aren't any pure go watson interpreters as far as i know so as long as you have to deal with some funny things happening um mostly uses like co behind the scenes um as well just dealing with like a lot of spec changes so yeah at a higher level just i don't know i sometimes you'll implement something and the spec changes and you have to go re-implement it and it takes up it takes twice as long as you expect it to take and that kind of thing um yeah so mostly yeah technically probably the runtime and then just in general just yeah spec changes trying to keep up with substrate that kind of thing awesome our last question for you why do we need a go implementation of this great question so um so every sort of network needs um multiple um implementations of the protocol um for like i mean many reasons but the main one is just that if there's a vulnerability or some issue um in one of the implementations hopefully the other implementations won't also have that issue so yeah this has been demonstrated on ethereum um a few times so yeah so just essentially having a more robust network um with many implementations of the protocols awesome let's get a clapping emojis to elizabeth elizabeth thank you so much for your time and the great presentation cool thank you so much awesome go ahead and unshare your screen and uh thank you so much yeah thank you dustin okay bye everyone Back To Top