Release Summary
Audience: ALL Community Members & Developers
“Asynchronous Backing” Phase 2
Asynchronous backing allows parallel execution or “pipelining” of transaction validation and block production in the relay chain.
There are 3 phases in order for a parachain to reap all the benefits of asynchronous backing. Runtime 2700 included the first phase, client 0.36 included the second. Runtime 2800 includes the third and final phase for Moonbase Alpha. (See the Polkadot wiki for more information on asynchronous backing and the 3 phase upgrade path a parachain must complete in order to fully adopt it.)
With async backing enabled, Moonbase Alpha will move from 12-second block time to 6-second. This is a great leap forward which will unlock new use cases requiring swift confirmation times like trading and payments. The 2x throughput also increases capacity to support more transactions and activity.
However, this has a number of implications for dApp developers and other infrastructure providers. Projects that are relying on blockheight to estimate time based on a 12-second block time will need to be recalibrated to account for this.
Since there will be double the number of blocks produced in a given time period, infrastructure providers providing storage and/or compute that grows with block production may need to make adjustments.
Project teams are encouraged to test out their applications and infrastructure in the Moonbase Alpha test environment to ensure a smooth transition to the new 6-second block time.
Enabling Asynchronous backing (and a 6-second block time) for Moonriver and Moonbeam is tentatively planned for RT2900 and RT3000 respectively. However, it should be noted that this is dependent on Async Backing being enabled on Kusama and Polkadot in those time frames.
Community Members (Governance)
Second Step to Disable Gov V1 (Democracy)
Gov V1 Democracy Proposals creation will be disabled in several stages on Moonbeam and Moonriver. It remained enabled on both networks as a safety measure for potential vulnerabilities in OpenGov, which has been active for about 7 months on Moonbeam and over 1 year on Moonriver. Despite this time frame, Gov V1 was never utilized on either network. The phased removal of Gov V1 commenced with disabling new democracy proposals creation in Runtime Upgrade 2700. followed by the complete removal of the Democracy pallet in subsequent runtime upgrades.
Runtime Upgrade 2800 is the second step in the dismantling of Gov V1 and contains the following changes:
- The Gov V1 Council and Tech Committee are removed
- The authority to trigger maintenance mode and freeze assets is transferred to OpenGov Technical Committee requiring a 5/9 threshold
- A special extrinsic is introduced which will be called following the runtime upgrade to release all Gov V1 voting locks
The final step which will occur in a future Runtime is to remove the Democracy pallet altogether.
Audience: Dapp Developers
Increase target block fullness from 25% to 50%
A block has a limit in terms of the number of units of gas that it can contain. Fees increase when a block exceeds the “block fullness” target and, conversely decreases when it is below.
When the dynamic fee model (EIP-1559) was implemented for all Moonbeam networks, the block fullness target was set to 25% as opposed to Ethereum which uses a target of 50%. The lower target was adopted in order to ensure a smooth transition to the new model.
In RT2801, the target is increased from 25% to 50% in order to be inline with Ethereum and to allow additional capacity within blocks without fees increasing.
Precompile to Verify Relay Chain Proofs
RT2800 adds a new precompile that can be called from smart contracts to verify the relay chain state in Moonbeam/Moonriver/Moonbase Alpha. The dApp needs to provide the queried state along with a proof that can be obtained via RPC. For example, a dApp could make an RPC call to the relay chain to retrieve an account’s DOT balance and provide it along with the corresponding proof to the precompile to verify this in a smart contract.
This removes the need for oracles between the relay chain and Moonbeam-based networks, making any oracle-dependent system less reliant on the centralization risks of such oracles.
Removal of “Local Assets”
The localAssets pallet will be removed from all environments beginning in Runtime 2801. This functionality was the first implementation of XC-20s and has been deprecated for some time. Some storage related to the localAssets pallet will remain but will be cleaned up in Runtime 2900.
Removal of ParachainStaking.Staked storage
The previously deprecated ParachainStaking.Staked storage item showing total amount staked across the network has been removed. Developers can use parachainStaking.total() instead.
Audience: End Users & Collators
Fix for “transferable amount” bug
This fixes an issue Introduced with the newer polkadot-sdk new account format where the transferable amount was inconsistent with the free amount available for paying for gas.
Audience: End Users
Fix for mismatching fees in ETH receipts
This fixes an issue where ETH receipts would report a slightly different fee amount than the actual fees charged to the account for an ethereum transaction.