Polkadot Release Analysis: Polkadot stable2407-1 & Polkadot stable2407-2
The following report is not an exhaustive list of changes included in the release, but a set of changes that we felt deserved to be highlighted due to their impact on the Polkadot ecosystem builders.
Please do not stop reading the release notes of Polkadot stable2407-1 & Polkadot stable2407-2. This report is complementary to the changelogs, not a replacement.
There is also a section related to all noteworthy changes related to integration tooling.
Summary
This analysis report is different from other release analysis reports. It contains a combined analysis of minor patch releases Polkadot stable2407-1 & Polkadot stable2407-2.
There is no major feature released in these releases. However, we are still covering some of the changes included in the Polkadot stable2407-1 & Polkadot stable2407-2. Runtime changes that are part of this release will be included in the corresponding runtime release done by the fellowship.
All the PRs analyzed in this report are low-impact.
Next to every PR name you can find the code base related to these changes. The notation is as follows:
- [S]: Changes related to Substrate
- [P]: Changes related to Polkadot
- [C]: Changes related to Cumulus
- [S/P/C]: Changes related to a combination of the noted code bases.
Tooling & Documentation Updates
Polkadot Stable2407-1
[C] StorageWeightReclaim: Fix issue when underestimating refund
Why is this important?
PoV-Reclaim is highly important for improving the scalability and efficiency of blockchain networks. It also provides better resource management and increased transaction capacity. It allows the reclamation of unused proof weight. POV-Reclaim works by calculating storage proof size as a difference between the extension’s post_dispatch and pre_dispatch recorded proof sizes.
At the moment, there is a bug that is underestimating the proof size while post dispatch call and overestimating the proof size during pre-dispatch call. As a part of this PR, this bug has been fixed.
Related Issue: #5229
[C] StorageWeightReclaim: set to node pov size if higher
Why is this important?
This release introduces one more change to PoV-Reclaim. As a part of this PR, a validation has been added to PoV-Reclaim, which will prevent the proof size from growing faster than the runtime proof size, because there might be situations when the node-side proof size is higher than the runtime proof size.
In case, if there is any difference between node-side proof size and runtime proof size, runtime bookkeeping will be set a node-side value.
Related Issue: #5229
Polkadot Stable2407-2
[S] Pallet-Timestamp: UnixTime::now implementation logs error only if called at genesis
Why is this important?
As a part of Remove most all usage of sp-std, an if condition was removed from Timestamp Pallet. This condition was logging error when UnixTime::now was called at the genesis block. That change was affecting the test output of several pallets (e.g. staking, EPM etc).
As a part of this PR, this has been fixed and the if condition has been re-introduced. Now the error log will be printed only when UnixTime::now will be called at genesis.
[C] Add feature to allow Aura collator to use full PoV size
Why is this important?
Presently, Aura collators are allowed to use half of the maximum PoV size for block building.
After this PR, builders will be able to enable a feature to use the full PoV size. This can be enabled by adding the following code in Cargo.toml:
[features]
# Allows collator to use full PoV size for block building
full-pov-size = []
Note: There is a warning issued about this PR. To use this feature, security considerations must be understood and the latest SDK version must be used.
[P] Always include UnpaidExecution, not just when revenue is nonzero
Why is this important?
Presently, the coretime assigner includes UnpaidExecution, when the revenue is nonzero. This was preventing NotifyRevenue XCM to pass the barrier from the relay to the coretime chain.
As a part of this PR, this has been fixed. From now on the coretime assigner will always include UnpaidExecution.