-
Notifications
You must be signed in to change notification settings - Fork 7
Add tutorial to perform forkless runtime upgrade #26
base: master
Are you sure you want to change the base?
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So far it LGTM. I'll take another look and follow it to validate the results 👍
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would like to see this tutorial down-scoped a bit with respect to the number of procedures that the participant is guided through (namely, I think we should remove the storage migration section), and elaborated a bit with respect to the concepts that remain. I think this tutorial does a pretty good job of walking the user through the mechanics of the steps, but I think there are some missed opportunities to demonstrate the fundamental concepts that underpin Substrate development; I do agree that this tutorial should be early on in the user journey because I think the concepts it encapsulates are so foundational to where we want to take them next. I think there should be 3 key concepts: runtime is part of consensus, the meaning of all the different versions and why we just change one, executing a dispatch as Root using Sudo.
Adding @joepetrowski as a reviewer. |
I like that this tutorial is split up across several pages as opposed to one big |
|
||
Once the upgrade transaction is included in a block, you should see a notification in the UI saying the a runtime upgrade has been performed, and the UI will need to be refreshed. Once you've refreshed, you can navigate to the "Extrinsics" tab, select "Template Module" from the dropdown, and see that our new extrinsic, `clear_value` is now available. | ||
|
||
Congratulations, you've upgraded your blockchain's runtime! Traditionally the process of upgrading a blockchain would have required a coordinated effort from all (or at least most) of the node operators in the network. But in this case, you have performed the upgrade in a single transaction without even causing a fork! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is a tricky one. On the one hand I think the text is good and emphasizes the point of the tutorial: substrate fixes the whole hard fork mess. On the other hand though it almost seems like sudo
is what makes this so easy, which is not the correct message.
The text clearly mentions Democracy
and Collective
above but I think it's worth repeating here that for a production blockchain, upgrading the runtime is not something a single entity can do at a whim?
I am not sure that newcomers to the blockchain space fully realize what a clusterfuck hard forks are in classical blockchains and how hard it is to get right.
Thanks for the proofing and contribution @dvdplm. I'm fine with a separate PR as you did in this case or with github suggestions. And for these kinds of changes where you fixed stuff that was just wrong, I'm fine with pushing directly to my PR branch. Does @danforbes or anyone else have interest in taking this one over? Dan, I'm fine with the suggestions you made. I just want to push back a little on cutting the storage upgrades. In general upgrades will require them and omitting that part sets users up to say, "I followed the tutorial on forkless upgrades and now my state is corrupted." That being said, if you do take this one over, it's totally up to you. |
I am fine with taking this over, Joshy. Any particular reason you're looking for someone else to pick this up? |
I want to suggest to split the tutorial and use part of it in POE. |
This PR introduces a new tutorial that picks up at the end of the start-your-frist-substrate-chain tutorial and takes the user through the process of performing two runtime upgrades. In the first upgrade they add an extrinsic and bump the spec version. In the second upgrade, they rename storage, migrate storage, and bump the spec version.
I consider this a rough draft. (There is even a TODO in there still). I'd like feedback from @danforbes as the owner of the tutorials. Feedback on any part of the tutorail is totally welcome as are commits pushed directly to this branch. Some specific things to think about.