Blockchains That Evolve with Your Business

Transcript

check hi everyone good morning so thank you for joining me here um my name is gotham dameja i work with parity technologies as a solutions director and today i'm going to talk to you about blockchains that evolve we have we have different kind of use cases we have different kind of users we have different kind of features and how do you make sure that the blockchains can keep up with those requests demands and issues all right so let's get started so the first thing i want to ask you is if you see my slide now what do you see that is a similarity between these three terms what do you think like you know is common among these three

exactly so people change we always want to become the best version of ourselves time changes i still have like 27 minutes left now because last moment i had 26 or 28 minutes left climate well it was 41 degrees yesterday in paris so climate is definitely changing and um clickers also change my clicker is not working right now it works now okay so uh blockchains it's a little hard to to make them change uh when there is a new something new and that needs to be done on a blockchain it takes some time to get it in there get it going and so on

so yeah it's hard to upgrade blockchains it's hard it's hard to get your blockchains together when it comes to change now with this premise i want to also like you know come to the point where we say that there is a change sometimes needed sometimes there are triggers sometimes there are circumstances that require you to upgrade your blockchain let's look at those okay this is the way protocol upgrades most of the time when uh when you want to change change the

protocol or you want to upgrade something on the core rules of the protocol there is a change required that needs to be done on the solution or on the app or on the smart contracts uh just to make sure that you are optimizing it for the latest version of the protocol or maybe your app represents a protocol in itself and you want to upgrade that optimizations are needed most of the time because uh when the market conditions change uh a lot of things change along with that and then you want to optimize your code to fit with those conditions of course uh you know like sometimes we want to fix things that were not uh so right in the first place so bug fixes are needed because it's just software at

the last and finally users and users come with requests so there are a lot of times when we want to incorporate those requests in our blockchain solutions so what do you see like you know all of these triggers or of all of these things require you to change the blockchain and what changes as part of those triggers what where does it impact the most where does where do you have to really change things is first of all of course the business logic uh whether it is in the smart contracts or in the core layer of your blockchain in the state transaction function itself incentives change because you know

people change like i said in the beginning when people change incentives have to change for them rules change because again it's the people thing and finally a lot of times the data needs to change as well like how you represent your data to make sure those optimizations are coming in so in the previous one we saw that there are some triggers these are the targets this is where the change actually happens and most of the time to incorporate all of this change the technology itself has to change the underlying technology that that we are mostly building on that changes as well so it basically is like you know everything keeps changing and then when we want to bring something together it it's hard to make make it from a

overview overall point of view so let's see how that looks as an example so i'm taking a very basic example here let's say there is a d5 platform and they want to incorporate some new protocol on there on their app essentially um and and because of this new protocol they are making some optimizations the data needs to change the schema needs to change and so on so they cannot just use upgradable smart contracts in this case it's it's hard because the data schema is changing there are a bunch of other things and it's a limitation now what you have to do in this case is all of this you have to first upgrade your smart contracts with the new version of the protocol then you have to migrate the data because the schema has changed

you have to then of course do the basic things test audit then deploy and finally the most important painful thing your users have to look at the new addresses of these smart contracts they have to update their side of things exchanges and wallets have to make the changes and this is painful this is not user friendly now let's look at another example for more from an enterprise perspective so most of the time this is how generally uh blockchains are implemented in in large scale systems that there are multiple parties coming together to verify data and let's say in this situation there are multiple parties and there is a new party that needs to join um

this particular consortium or solution or or whatever you want to call it and uh this brings together with some new parameters some new integration aspects and so on so then this again requires a change in your system this requires you to upgrade some of the parameters that you are already working with requires you to integrate some new systems through oracle's or or so on and then again the same painful process comes back so update the smart contracts migrate the data and blah blah blah so it's when we want to really change something we have to go through a lot and this is uh essentially slowing slowing you down this is essentially making making things uh much more you can say slower to market in in this

in this time when blockchain technology itself is moving so fast we want to go so so quickly to the market with our products and try them out this process just doesn't allow that this process makes us slow so what do we do now it's not just about the technology it's not just about this particular process or so on there is more there is more to it the governance aspect so there is no admin there is no one single person then can just go and upgrade something or even if it is allowed if even if it is needed it's it's it's really uh impossible so how do we ensure that we align these old different stakeholders to actually agree on something in a faster manner in

a more efficient manner because if you look at how off-chain governance is done these days it's like you know people want to collaborate on calls and google docs and everything but how much of that really goes on the chain and how fast and the first uh the more important thing is how do you enact those rules that you have been talking about with these different people so it's again there is a technology problem and there is a people problem and how do we bring this all together so that is where um we call something as evolving blockchains the it's it's more like you know uh an abstract idea but the concepts that i'm going to talk

about now it's going to bring this together so bear with me and and let's take a look at what what this really means so let's think about these two problems the technology problem and the people problem what if we have a very efficient on-chain governance process will that make things faster from a people perspective will that allow us to quickly agree on something in a most verifiable manner and then try to enact those things on the chain so that that is where you know like we want to simply look at the people problem and tackle it in a more efficient manner what if people don't have to fork at all what if they just can get their blockchains upgraded with a

much more simple and seamless process that there is a transaction a special transaction that happens with everybody's agreement on it maybe a multi-sig maybe a democracy related voting mechanism and then that transaction happens and everybody's nodes gets upgraded forkless what if the state migration or the storage migrations that users have to worry about that exchanges have to worry about can have can be done in a automated fashion can it can abstract away every pane from the user and can be part of the runtime upgrade process or the blockchain upgrade process itself and finally what if you have a completely extensible framework that allows you to go from version one to version two in a much

faster and scalable manner what if you can just you know like build on top of what you have instead of building something from scratch instead of not reusing the primitives that you have already defined so i look at these four things as pillars of evolving blockchains if you have these four things if you can work on them uh on your blockchain solution then probably your blockchains will evolve faster they will be faster to market they will be closer to your users and they will probably bring you feedback in a more efficient manner so this is where substrate comes into the picture this is uh essentially you must have heard of uh this framework that parity has created this is uh this is basically and blockchain development

sdk built in rust and um it allows all of those four things to have evolving blockchains so let's take a look at all of all of those things together on-chain governance so essentially substrate just to give you a little bit of a brief um you know like overview substrate is is a fully extensible and modular framework and and this has basically a thing called runtime which is basically the state transition function of the blockchain and that is composed of different kind of modules which we call pallets now substrate has these inbuilt on-chain governance pallets that ship with substrate fully audited fully production ready and then you can use them in your blockchain at

any point in time so your blockchain can become completely on chain governed by using these pallets and you can extend and you can improve them if you want if you want you know like a more fancy version of these you can just build on top of these so that's the first pillar of evolving blockchain supported by substrate the on-chain governance four class upgrades um again the second pillar of evolving blockchains what if there is no fork needed what if no people don't have to download a new node every single time there is a change in the blockchain happening what if there is a special transaction that happens through the governance process this is it so substrate basically the state

transition function the runtime is is just a wasm blob and this special transaction that the forklift upgrade transaction that we call it can simply replace this wasm block with the next version and everybody gets the same uh you know like run time on their nodes so they don't have to download a new node at all they don't have to worry about basically forking the chain or connecting to another fork or so on it can just simply get upgraded using this process and it can be upgraded by all the nodes are still running nobody has to stop their nodes as well so again forecast upgrades supporting evolving blockchains state migrations or

storage migrations so when when the upgrade really happens in substrate it allows a couple of hooks where you can write some functions which we call migration functions and they can just pick up the state from the old state or the old schema and put that into the new schema while as part of the upgrade process so basically you can write your migrations it's just simple like you know writing um simple functions where you pick up the data and put that in the new storage you run the upgrade process the spatial transaction and then after that a hook comes in which is called on runtime upgrade where this function can run and migrate all of the data for your users you don't even have to worry about anything

and finally extensibility so think of a scenario where you have a node and you just have to upgrade upload or deploy smart contracts on it that's a pretty black box approach you don't have any control on the state transition function itself you don't have any control on optimizing those smart contracts for different kind of use cases you just need to deploy those smart contracts not user friendly not developer friendly pretty much but what if you have full control on extending everything inside your blockchain you can change the consensus you can change the cryptosuite itself you can change the apis and networking storage everything of course substrate comes

pre-packaged with a very optimized implementation of each of these things but you are fully free to you know extend any of those if you have uh you know something written in rust and then of course the straight transition function which i spoke about previously in the forecast upgrade spark this is awesome blob which is of course upgradeable at runtime so extensibility allows you to ex basically build on top of what you already have with the same primitives and allows you much faster upgrade or much faster faster change in your blockchain so that's the fourth pillar so if you bring all of these things together your blockchains become much more evolving i believe so

maybe it's not so hard to upgrade blockchains anymore if if we are using substrate it's it's more like you can say a way to go faster to the market a way to cater to your users much much more seamlessly and much more efficiently and a way to actually have more fun while building blockchain solutions from a developer's perspective because you can try different things you can experiment you can you can essentially evolve with the solution as your knowledge as well so now just to give you a little bit of sneak peek into what this looks like in the real world some stats from from our ecosystem so in the polkadot ecosystem we have had more than 100 forecast

upgrades in the last few months itself the community came together the governance played a part in this and then when everybody agreed we did a four-class upgrade of of the protocol more than 1400 engaged participants participated in these upgrades from the governance process and finally in the entire ecosystem we have had 621 plus forecast upgrades across all of you can say substrate based chains in the polka dot and kusama ecosystem so what i spoke about this really works this is already in practice this is fully production ready and people are using it so that is evolving blockchains for you thank you so much for listening any questions

[Applause] testing yep so um yeah some of these changes um yeah look like obviously at the blockchain level it's quite a fundamental change um [Music] like is there any granularity of the users that can opt into that or opt out of that so would you effectively get forks of the blockchain just by virtue of people sort of signaling into the change or not or is it majority votes and then everyone changes across because i just think of use cases where um someone may have had an expectation of

certain functionality for the long term so they built their smart contracts got them altered and all that process but then effectively the floor has shifted from under them because it's at that lower level is is there a way that they can preserve the chain they started on or do they just have to take this um upgrade so uh i think there are uh there are two two things here um first of all thank you for the question very very good question because um i forgot to mention one thing that this smart uh this upgrade process is for the state transition function of the chain essentially it is not for these smart contracts so it is one layer below already so when you are building your chain using substrate not just the smart contracts the entire blockchain for your

use case then you are basically able to upgrade and then your community plays a role in upgrading that uh chain essentially so if if the if the users are still deploying smart contracts on top their smart contracts are not changing at all it's just the straight transition function that is changing but in most cases because these chains are fully user use case optimized they are application specific chains that is why the smart contracts are not on top of them the state transition function plays all the major roles in terms of functionality already so this is not for smart contract platforms but for application specific blockchains there was one more question um thank you for the presentation so if i

understand correctly so you already have more than 100 upgrades on layer 0 and polkadot and kusama and so it's something maybe similar to the other questions i guess it's really the governance that is important in this case because you should agree to upgrade how do you what is the consensus and how can you participate to these consensus so essentially anyone who who wants to participate can participate they just need to you know when when you are voting you need the dot token or the ksm token when you are participating in the governance process so as far as you have uh the token um you can participate in the governance it's fully open fully

decentralized okay and in terms of consensus how much do you expect to um like for ho ho he's worked as a quorum is that you you need fifty percent of uh or fifty one percent of the voters it's basically uh you know like uh different from uh proposal to proposal essentially so when people propose something sometimes you know like the majority or super majority consensus is needed sometimes you know like normal majority sometimes it's a council based uh consensus that is needed and so on but there is a new version of governance also coming in it's it's underway like uh last a couple of weeks ago it was

announced in polkadot decoded that we are working on governance version two which will make this even more you can say uh flexible and configurable in the future thank you very much all right thank you everyone have a nice morning you