Exercise 05

Objectives: writing pallets, storage migration, try-runtime

Needs: Exercise 04

Content: We are going to change the logic of the banishment pallet a little. Instead of banishing an account forever, we will banish it only for a fixed number of sessions.

  1. Modify existing pallet so that it supports new semantics. For this, update your existing storage item. Moreover, you will need to listen for session changes. You can check e.g. the elections pallet for how we interact with the session pallet. Ensure that your pallet stores only the accounts that are currently banished. Entities for which the banishment period has ended, shouldn't take up space unnecessarily.

  2. Since we will introduce new changes as runtime update (to a running chain), you should also provide a runtime migration. Take a look at the pallets aleph and elections for how to write migrations. For migration test helpers consult pallets-support crate.

  3. Launch a new chain with the old version of the banishment pallet. Test your migration with the try-runtime tool.

  4. Perform a proper runtime update. Verify that the new API works as expected.

  5. Repeat the experiment, but this time ensure that the old storage is not empty:

    1. Restart the old chain.

    2. Banish some account (should be marked as banished forever).

    3. Perform the update.

    4. Check whether the banished account is still considered banished.

Some decisions, like the length of banishment period, and treatment of previously banished accounts are up to you.

Hint

Actually, there are (at least) two solutions. The first one (simpler) is to define a new trait like SessionInfoProvider and provide a default implemention for pallet_session. This, however, requires hooking on every block (in order to check whether a new session has begun).

The second one (optimal) is to use SessionHandler trait from Substrate. It provides subscription for session beginning, but is trickier to configure.

References:

Last updated

Was this helpful?