Skip to content
This repository has been archived by the owner on Nov 15, 2023. It is now read-only.

follow-chain testing mode for try-runtime (and revamp CLI configs). #9788

Merged
19 commits merged into from
Sep 21, 2021

Conversation

kianenigma
Copy link
Contributor

@kianenigma kianenigma commented Sep 15, 2021

closes #9027
closes #9570
somewhat related #2082

And does a major cleanup and revamp of the try-runtime cli to hopefully make it more easy to use.

polkadot companion: paritytech/polkadot#3858

And, finally, it adds a new follow-chain command to try-runtime. This will copy a live chain's state, dump it into a TestExternalities as usual, and keep applying the extrinsics of a live chain as new block come in using the current runtime. This means running this with wss://rpc.polkadot.io in substrate is nonsense since it will try and decode + execute polkadot blocks in substrate-node.

@sacha-l some arguments change in this PR. Can you make an issue in the devhub to update the docs? it should be fairly simply to update, if any.

Using this is still tricky, there are a few considerations:

  1. Let's say you are on top of branch master of polkadot. If the block decoding has changed in any way since the live node from which you are pulling things, nothing will work.
  2. Block decoding will work, but then you have to manually tweak your transaction/spec version to match the one on the live node, since they are part of the signature verification. I am looking into ways to actually disable signature verification in this try-runtime entirely, to make this part a bit easier.

An alternative flow to avoid the previous caveats is that you would backport your feature branch to the branch of the latest release, ensuring that almost certainly the above two variables have not changed (unless if your feature branch is literally changing the block format etc.)

  • add a ton more docs
  • allow live::at to be omitted, and replaced with the latest finalized block.
  • prevent execution on wrong chain.
  • mock signature verification. UPDATE: can mock the signature verification, but then this messes with the signed extension executions. The situation was that I would get a ExhaustResource error this time, if the spec-versions did not match. I might revisit this in the future. For future references, this is the commit that removes mocking signature verification: 7d60da9 (#9788)
  • clean some of the unwraps.

A different, more cumbersome, but more realistic way of doing this is:

Use fork-of-substrate and create a new chain. Use a custom runtime in there that is your feature branch + sudo or some other pallet that allows us to execute arbitrary transactions. Then run this chain in the same was as fork-of-substrate, and run binary next to it that scans a live chain, and forwards the new transactions to the "backdoor" (e.g. sudo) of the forked chain.

This is obviously too much work. Maybe the only worthwhile way of doing this is if we establish RPC connections in the fn offchain_worker, and make it all seamless. So, you'd have a feature branch. You add this new magic-testing-pallet to it, and run it, and it would mirror a real chain for you.

The current scheme also allows for rather easy scripting and testing, other than being simpler.

@kianenigma kianenigma added A3-in_progress Pull request is in progress. No review needed at this stage. B5-clientnoteworthy C1-low PR touches the given topic and has a low impact on builders. D2-notlive 💤 PR contains changes in a runtime directory that is not deployed to a chain that requires an audit. labels Sep 15, 2021
@niklasad1
Copy link
Member

Block decoding will work, but then you have to manually tweak your transaction/spec version to match the one on the live node, since they are part of the signature verification. I am looking into ways to actually disable signature verification in this try-runtime entirely, to make this part a bit easier.

Can't you subscribe/poll runtime_version on the remote node to detect if transaction/spec version changes?

@kianenigma
Copy link
Contributor Author

Can't you subscribe/poll runtime_version on the remote node to detect if transaction/spec version changes?

sure, but what would you do about it other than stopping? that's practically equal to what I do now, which is decode.unwrap() :D

@niklasad1
Copy link
Member

yeah right, dumb question I guess it's not much to do without updating.....

@kianenigma kianenigma added A0-please_review Pull request needs code review. and removed A3-in_progress Pull request is in progress. No review needed at this stage. labels Sep 16, 2021
@kianenigma kianenigma marked this pull request as ready for review September 16, 2021 14:09
@kianenigma kianenigma changed the title follow-chain testing mode for try-runtime (and other minor fixes). follow-chain testing mode for try-runtime (and other fixes). Sep 16, 2021
@kianenigma kianenigma changed the title follow-chain testing mode for try-runtime (and other fixes). follow-chain testing mode for try-runtime (and revamp CLI configs). Sep 16, 2021
Comment on lines 235 to 238
// don't call `final_checks`, but do finalize the block. This is critical to clear transient
// storage items, such as weight.
let _header = <frame_system::Pallet<System>>::finalize();

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Would wonder if there is some migration that would pass all the tests written, but then actually cause a problem on final checks, but we dont see that now

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

unlikely, but yeah that's just a pill that we have to swallow here. Final checks does:

  1. header digest check (don't know what it does -- not is it relevant IMO)
  2. state root check
  3. extrinsic root check

This actually makes me think: maybe I can re-introduce item 1 and 3, since they should work. Only the state root is guaranteed to fail, since :CODE: has changed.

use remote_externalities::{rpc_api, Builder, Mode, OfflineConfig, OnlineConfig, SnapshotConfig};
//! # Try-runtime
//!
//! Substrate's ultimate testing framework for the power users.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

kian pats himself on the back

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

shamelessly advertising 😅

Copy link
Member

@shawntabrizi shawntabrizi left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks reasonable at a high level. Can scrub deeper if needed

@kianenigma
Copy link
Contributor Author

bot merge

@ghost
Copy link

ghost commented Sep 21, 2021

Waiting for commit status.

@ghost ghost merged commit 04bb4e0 into master Sep 21, 2021
@ghost ghost deleted the kiz-try-runtime-execute-block-no-check branch September 21, 2021 15:04
ghost pushed a commit to paritytech/polkadot that referenced this pull request Sep 21, 2021
* companion for paritytech/substrate#9788

* fmt

* Some fixes

* final fixes

* fix a few small things

* update Substrate

Co-authored-by: parity-processbot <>
chevdor pushed a commit that referenced this pull request Sep 23, 2021
…#9788)

* deadlock, need to ask someone to help now

* Finally it seems to be working.. at least for a few blocks

* self-review

* major mega revamp

* some small fixes

* another mega refactor

* add license

* Apply suggestions from code review

* hack around signature verification

* Some fixes

* Update utils/frame/try-runtime/cli/src/lib.rs

Co-authored-by: Zeke Mostov <32168567+emostov@users.noreply.github.com>

* Update utils/frame/try-runtime/cli/src/lib.rs

Co-authored-by: Zeke Mostov <32168567+emostov@users.noreply.github.com>

* Update utils/frame/try-runtime/cli/src/lib.rs

Co-authored-by: Zeke Mostov <32168567+emostov@users.noreply.github.com>

* final tweaks, hopefully.

* a little self-review

* Add the ext root check

Co-authored-by: Zeke Mostov <32168567+emostov@users.noreply.github.com>
chevdor pushed a commit to paritytech/polkadot that referenced this pull request Sep 23, 2021
* companion for paritytech/substrate#9788

* fmt

* Some fixes

* final fixes

* fix a few small things

* update Substrate

Co-authored-by: parity-processbot <>
@chevdor chevdor mentioned this pull request Sep 23, 2021
kianenigma added a commit to kianenigma/seeding that referenced this pull request Sep 27, 2022
# Membership Request 

Hi, I am Kian Paimani, known as @kianenigma. I have been working on Polkadot/Kusama through Parity since February 2019 and I can categorize my main contributions to Polkadot's ecosystem as follows: 

1. Maintaining and developing the staking sub-system.
2. General FRAME development, especially testing and quality assurance. 
3. Polkadot-native side-projects. 
4. Education 

> My first contribution to Polkadot is also indeed related to staking: paritytech/substrate#1915

### Staking system

I joke as the Polkadot staking to be both my blessing and my curse over the years. I started working on it since the first days that I joined this ecosystem and the work [is ongoing ever since](https://github.com/orgs/paritytech/projects/33/views/9). In the past, I focused on making sure that the staking system is secure and to some extent scalable. More recently, I coordinated the (imminent) launch of Nomination Pools. Nowadays I also put an extra effort on making sure that this sub-system of Polkadot is *sustainable*, through code refactor and educating other core developers. 

Lastly, I have been the main author of the [Polkadot staking newsletter](https://gist.github.com/kianenigma/aa835946455b9a3f167821b9d05ba376), which is my main attempt at making the entire complexity and development of this part of the protocol transparent to the end-users.

I expect myself to contribute *directly* to the staking system for at least another ~12, if not more, and afterwards having the role of an advisor. 

Some notable contributions: 

- paritytech/substrate#4517
- paritytech/substrate#7910
- paritytech/substrate#6242
- paritytech/substrate#9415
- paritytech/polkadot#3141
- paritytech/substrate#11212
- paritytech/substrate#12129

### FRAME 

Historically, I have contributed a variety of domains in FRAME, namely: 

- Early version of the weight system paritytech/substrate#3816 paritytech/substrate#3157
- Early version of the transaction fee system
- Primitive arithmetic types paritytech/substrate#3456
- Council election pallet paritytech/substrate#3364

Many of which were, admittedly, a PoC at most, if not considered "poor". I am happy that nowadays many of the above have been refactored and are being maintained by new domain experts. 

These days, I put most of my FRAME focus on testing and quality assurance. Through my work in the staking system, I have had to deal with the high sensitivity and liveness requirement of protocol development first hand (I believe I had to do among the [very first storage migrations](paritytech/substrate#3948) in Kusama) and consequently I felt the need to make better testing facilities, all of which have been formulated in https://forum.polkadot.network/t/testing-complex-frame-pallets-discussion-tools/356. Some relevant PRs:

- paritytech/substrate#8038
- paritytech/substrate#9788
- paritytech/substrate#10174

Regardless of wearing the staking hat, I plan to remain a direct contributor to FRAME, namely because I consider it to be an important requirements of successfully delivering more features to Polkadot's ecosystem. 

### Polkadot-Native Side Projects

I have started multiple small, mostly non-RUST projects in the polkadot ecosystem that I am very happy about, and I plan to continue doing so. I have not yet found the time to make a "polished product" out of any of these, but I hope that I can help foster our community such that someday a team will do so. I consider my role, for the time being, to *put ideas out there* through these side projects. 

- https://github.com/substrate-portfolio/polkadot-portfolio/
- https://github.com/kianenigma/polkadot-basic-notification/
- https://github.com/paritytech/polkadot-scripts/
- https://github.com/paritytech/substrate-debug-kit/

### Education 

Lastly, aside from having had a number of educational talks over the years (all of which [are listed](https://hello.kianenigma.nl/talks/) in my personal website), I am a big enthusiast of the newly formed Polkadot Blockchain Academy. I have [been an instructor](https://singular.app/collectibles/statemine/16/2) in the first cohort, and continue to contribute for as long and as much as I can, whilst still attending to the former 3 duties. 

---

With all of that being said and done, I consider myself at the beginning of the path to Dan 4, but happy to start at a lower one as well.
bkchr added a commit to polkadot-fellows/seeding that referenced this pull request Sep 27, 2022
# Membership Request 

Hi, I am Kian Paimani, known as @kianenigma. I have been working on Polkadot/Kusama through Parity since February 2019 and I can categorize my main contributions to Polkadot's ecosystem as follows: 

1. Maintaining and developing the staking sub-system.
2. General FRAME development, especially testing and quality assurance. 
3. Polkadot-native side-projects. 
4. Education 

> My first contribution to Polkadot is also indeed related to staking: paritytech/substrate#1915

### Staking system

I joke as the Polkadot staking to be both my blessing and my curse over the years. I started working on it since the first days that I joined this ecosystem and the work [is ongoing ever since](https://github.com/orgs/paritytech/projects/33/views/9). In the past, I focused on making sure that the staking system is secure and to some extent scalable. More recently, I coordinated the (imminent) launch of Nomination Pools. Nowadays I also put an extra effort on making sure that this sub-system of Polkadot is *sustainable*, through code refactor and educating other core developers. 

Lastly, I have been the main author of the [Polkadot staking newsletter](https://gist.github.com/kianenigma/aa835946455b9a3f167821b9d05ba376), which is my main attempt at making the entire complexity and development of this part of the protocol transparent to the end-users.

I expect myself to contribute *directly* to the staking system for at least another ~12, if not more, and afterwards having the role of an advisor. 

Some notable contributions: 

- paritytech/substrate#4517
- paritytech/substrate#7910
- paritytech/substrate#6242
- paritytech/substrate#9415
- paritytech/polkadot#3141
- paritytech/substrate#11212
- paritytech/substrate#12129

### FRAME 

Historically, I have contributed a variety of domains in FRAME, namely: 

- Early version of the weight system paritytech/substrate#3816 paritytech/substrate#3157
- Early version of the transaction fee system
- Primitive arithmetic types paritytech/substrate#3456
- Council election pallet paritytech/substrate#3364

Many of which were, admittedly, a PoC at most, if not considered "poor". I am happy that nowadays many of the above have been refactored and are being maintained by new domain experts. 

These days, I put most of my FRAME focus on testing and quality assurance. Through my work in the staking system, I have had to deal with the high sensitivity and liveness requirement of protocol development first hand (I believe I had to do among the [very first storage migrations](paritytech/substrate#3948) in Kusama) and consequently I felt the need to make better testing facilities, all of which have been formulated in https://forum.polkadot.network/t/testing-complex-frame-pallets-discussion-tools/356. Some relevant PRs:

- paritytech/substrate#8038
- paritytech/substrate#9788
- paritytech/substrate#10174

Regardless of wearing the staking hat, I plan to remain a direct contributor to FRAME, namely because I consider it to be an important requirements of successfully delivering more features to Polkadot's ecosystem. 

### Polkadot-Native Side Projects

I have started multiple small, mostly non-RUST projects in the polkadot ecosystem that I am very happy about, and I plan to continue doing so. I have not yet found the time to make a "polished product" out of any of these, but I hope that I can help foster our community such that someday a team will do so. I consider my role, for the time being, to *put ideas out there* through these side projects. 

- https://github.com/substrate-portfolio/polkadot-portfolio/
- https://github.com/kianenigma/polkadot-basic-notification/
- https://github.com/paritytech/polkadot-scripts/
- https://github.com/paritytech/substrate-debug-kit/

### Education 

Lastly, aside from having had a number of educational talks over the years (all of which [are listed](https://hello.kianenigma.nl/talks/) in my personal website), I am a big enthusiast of the newly formed Polkadot Blockchain Academy. I have [been an instructor](https://singular.app/collectibles/statemine/16/2) in the first cohort, and continue to contribute for as long and as much as I can, whilst still attending to the former 3 duties. 

---

With all of that being said and done, I consider myself at the beginning of the path to Dan 4, but happy to start at a lower one as well.

Co-authored-by: Bastian Köcher <git@kchr.de>
ggwpez pushed a commit to ggwpez/runtimes that referenced this pull request Mar 10, 2023
* companion for paritytech/substrate#9788

* fmt

* Some fixes

* final fixes

* fix a few small things

* update Substrate

Co-authored-by: parity-processbot <>
ggwpez pushed a commit to ggwpez/runtimes that referenced this pull request Jul 13, 2023
* companion for paritytech/substrate#9788

* fmt

* Some fixes

* final fixes

* fix a few small things

* update Substrate

Co-authored-by: parity-processbot <>
This pull request was closed.
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
A0-please_review Pull request needs code review. C1-low PR touches the given topic and has a low impact on builders. D2-notlive 💤 PR contains changes in a runtime directory that is not deployed to a chain that requires an audit.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

try-runtime: don't require --block-at in snapshot [try-runtime-cli] Improve header info retrieval
4 participants