FRAME monthly update

This here is a temporary solution to communicate updates from the Parity FRAME team to the community. We’re thinking of a more structured way to do this and would like to know if in general this is helpful to the ecosystem.

With that said here comes our first public monthly update reflecting the team’s contributions of October 2023


TLDR;


DevX

  • Thetry-runtime-cli has seen performance optimisations, new spec_version checks, and improved PoV checks, and CI compatibility :sparkles:

  • For the upcoming months @liamaharon and @juangirini will be taking over @kianenigma ’s documentation endeavour and lead the developer hub project.

    A first version of the developer_hub is temporarily deployed here. If you want to give feedback or share your findings, please go ahead and report it in the repo. :mag:

Staking

  • A paging system for reward payouts in the NPoS was implemented and will bring an improved rewarding mechanism to nominators once it makes it to the runtime upgrade :partying_face: With these changes rewards will be payed out to nominators in a paginated manner. If a validator has more nominators than the page size, a function can be called multiple times to process all the pages.

    Furthermore the commission payout for validators was adjusted to ensure it’s distributed fairly across all pages of nominators and the PR includes a new storage upgrade to support the new paginated approach.

    This change needs to be reflected in the staking dashboard and might have an impact on several other projects, so feel free to reach out to @ankan if you have any questions.

  • The stake-tracker pallet is ready to be reviewed. The main goal of this feature is to harden the security of the staking system as the number of validators scale up.

  • In the upcoming updates we will be able to celebrate some movements around nomination pool funds being able to used for participating in governance voting and the staking chain :raised_hands: Stay tuned…

Message passing & XCM

  • :tada: Another big achievement is the merge of the refactors in the DMP and XCMP dispatch queue
    The DMP pallet has been entirely replaced by the MessageQueue (MQ) and removed, which allows for PoV-bounded execution and solves several issues related to the previous workaround. The MQ pallet now adopted the functionalities of:
    • Enqueuing XCMP messages for deferred processing
    • Directly managing overweight messages
    • Process messages during the on_initialize hook, a change from the previous system where processing was triggered in set_validation_data
  • The XCM v4 audit was completed and most feedback has been addressed. In the meanwhile @francisco.aguirre is trying to gather more feedback irt XCM user & developer experience and will initiate a project based on the requirements resulting from it. One step towards this was the syntax improvement for writing XCMs :rocket:
  • The XCMFeesToAccount struct was merged. It introduces XcmFeesToAccount, assigning it as the FeeManager in all runtimes configurations. This struct ensures XCM execution fees are deposited into the treasury account. The update includes the implementation of XCM delivery fees and XCM instructions now require origin accounts to pay the transport delivery fees (this fee is added to the already existing BuyExecution tx fees). Wallet UIs can calculate these new fees using a provided formula.

FRAME Proper

  • The syntax for marking calls “feeless” PR is open and ready for review. The syntax marks operations that could be performed without the usual requirement of paying transaction fees or needing the user’s account to have a specific minimum balance. This will be beneficial for use cases where you want to bring new users who don’t have DOTs in their wallet yet. For example, people who got a certain NFT could now trigger some transactions where the NFT acts as a ticket.

  • As part of moving pallets over to use fungible traits the multisig pallets were adapted and will be soon open for review. The goal of this meta issue is to standardise the way different pallets handle interchangeable (fungible) assets.

  • Soon ready and eager for reviews and audit is the implementation of the RFC#13 introducing Multi-Block-Migrations, a new pallet poll and replacement hooks for on_initialize and on_finalize . :clap: These migrations allow updates to be split over multiple blocks, rather than requiring a single block to make large changes. It will also play a major role in the before mentioned migration of pallets to use fungible traits.

    Multi-Block-Migrations (MBM): Implemented via a new pallet_migrations. The system enters a lockdown during an MBM, preventing transactions in a block. This feature requires a SteppedMigration trait for migrations that proceed in steps and has safeguards against runtime upgrades during migrations.

    poll hook: A new pallet hook to replace the on_initialize callback to prevent migration issues that could lead to broken storage invariants.

    Hard-Deadline Callbacks: New callbacks (PreInherents, PostInherentsPostTransactions) are introduced in System::Config to replace and on_finalize where cannot be used, ensuring clarity on code execution deadlines.

    General FRAME Changes: Updates to frame_system pallet configuration items, including new ways to define single and multi-block migrations, and the introduction of pre and post inherent callbacks to better manage the execution sequence during a block’s lifecycle.

8 Likes