RT2900/RT2901 Release Summary
Audience: All Community Members
Async Backing: Increase Gas Parameters by 4x on Moonbase Alpha
Parameters related to gas limits have been increased by a factor of 4 on Moonbase Alpha. Therefore, the EVM max gas limit is increased from 15M to 60 M. This was made possible by the adoption of Asynchronous Backing.
When considering a simple transaction such as an ERC-20 transfer, the throughput of Moonbase Alpha has increased by 8x (given the 4x max gas increase coupled with a reduction of the block times from 12 to 6 seconds).
However, it should be noted that the PoV (Proof-of-Validity) size is still limited to 5 MB, and several parameters impose limitations on what can be included in a block aside from the EVM max gas per block. These include the storage growth limitation introduced in MBIP-5 and max execution time. Although these parameters have also been increased, actual throughput will vary based on the nature of the transactions in a given block.
Moonriver in RT3000 and Moonbeam in RT3100 are planned to have a 6-second block time and increase gas parameters by 4x.
Project teams are encouraged to test their applications and infrastructure in the Moonbase Alpha test environment to ensure a smooth transition to the new 6-second block time.
Audience: Core Developers & Community
Upgrade to Polkadot-SDK 1.7.2
In RT2900, the Polkadot SDK is upgraded to 1.7.2 from 1.3.0. It’s important that the Moonbeam runtime stays relatively current with the Polkadot SDK to continue operating smoothly in the Polkadot ecosystem. Generally, the Moonbeam core developers will look to update the Polkadot SDK version every other release, as it is a significant amount of work.
The upgrade to 1.7.2 contains many improvements across a multitude of “pallets”. It ensures that Moonbeam will be well positioned to leverage advancements in the Polkadot network such as Snowbridge, AssetHub, and improvements to Asynchronous Backing, XCM and Agile Core Time. See the Polkadot SDK release notes for more information.
Pausing of XCM message processing in case of stopped block production
Processing of XCM messages will pause if block production stops on Moonbase Alpha.
When XCM messages arrive on a parachain, the parachain is obligated to queue and process them. However, transactions arriving via XCM bypass certain checks, typically occurring when transacting directly via the EVM or substrate.
In a situation in which the chain were to stall as a result of some sort of XCM spam attack, the pausing of XCM message processing is a safety measure that could allow the OpenGov Technical Committee to take corrective action without the need to go through Polkadot Governance.
Assuming testing goes well, this feature will be deployed to Moonriver and Moonbeam in a future release.
Audience: Community Members (Governance)
Final Step to Disable Gov V1 (Democracy)
Runtime Upgrade 2901 is the final step in the dismantling of Gov V1. All democracy locks have been released in a migration, and the Democracy Pallet has been removed altogether.
FastGeneralAdmin Track added to Moonriver and Moonbeam (Democracy)
The new “FastGeneralAdmin” Governance track which was added to Moonbase Alpha in RT2800 is being added to Moonriver and Moonbeam in order to facilitate faster XCM channel openings.
See this forum post for details.
Audience: Dapp & Core Developers
XCM Fee Payment Improvement
Allow fee payment using assets in the sovereign account when transacting with XCM via Governance. This means the “fee_payer field” field is now optional when using “transact_through_sovereign”. When the fee payer is not included, the XCM execution will use funds that are stored in Moonbeam’s sovereign account in the destination chain. Therefore, the proposer needs to ensure there is a surplus of funds to submit the governance proposal if this optional field is not used.
Audience: Dapp Developers & End Users
Fix for Incorrect refunds
This fixes an issue where refunds relating to “external costs” (e.g. PoV, MBIP-5) were not done correctly for some transactions.
Audience: Collators and Core Devs
Fix for Collator Creating two Consecutive Blocks
It fixes an issue where a collator might create two consecutive blocks, which were introduced by Asynchronous Backing. The “velocity” parameter is reduced from 2 to 1, resulting in a more predictable block production.