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
- For a better DevX the
try-runtime-cliwas optimised and a first version of the
developer_hubis up and waiting for feedback.
- A new rewarding mechanism to payout nominators was implemented, after adapting the staking dashboard accordingly, it can make it’s way to a new runtime upgrade.
- The staking team is working on hardening the security by scaling the number of validator candidates, more to that can be found in the new
DMPpallet has been entirely replaced by the
MessageQueue(MQ) and removed.
- XCMv4 is getting ready and there has been some improvement on the syntax for writing XCMs.
- A discussion started in the Polkadot Forum in order to gain more feedback for further DevX improvement irt XCM.
XCMFeesToAccountstruct was merged introducing new XCM fees and a mechanism to manage these fees.
- We’re introducing a syntax for marking calls “feeless” and adapted the multisig pallets to use
- Coming : the implementation of the RFC#13
try-runtime-clihas seen performance optimisations, new spec_version checks, and improved PoV checks, and CI compatibility
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 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.
stake-trackerpallet 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 Stay tuned…
Message passing & XCM
- Another big achievement is the merge of the refactors in the DMP and XCMP dispatch queue
DMPpallet 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_initializehook, a change from the previous system where processing was triggered in
- 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
XCMFeesToAccountstruct was merged. It introduces
XcmFeesToAccount, assigning it as the
FeeManagerin 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
BuyExecutiontx fees). Wallet UIs can calculate these new fees using a provided formula.
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
fungibletraits 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
polland replacement hooks for
on_finalize. 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
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
SteppedMigrationtrait for migrations that proceed in steps and has safeguards against runtime upgrades during migrations.
pollhook: A new pallet hook to replace the
on_initializecallback to prevent migration issues that could lead to broken storage invariants.
Hard-Deadline Callbacks: New callbacks (
PostInherentsPostTransactions) are introduced in
System::Configto replace and
on_finalizewhere cannot be used, ensuring clarity on code execution deadlines.
General FRAME Changes: Updates to
frame_systempallet 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.