#69 Runtime 1801 Upgrade
The Moonriver Council proposes to upgrade the Moonriver's runtime to version version 1801. This upgrade will include the Runtime 1800 change proposal along with the below fixes.
Runtime 1800 release note :
https://github.com/PureStake/moonbeam/releases/tag/runtime-1800
Fixes : https://github.com/PureStake/moonbeam/releases/tag/runtime-1801
Verification
Blake2_256 Hash: 0x1dd8a942765d78ec1cc9b3e5e695167656726105b8b275c682087e6983bb245d
If you want to apply the best practices and verify the hash of the proposal, we advise you to use srtool
Show More
Proposal: Increasing the WASM heap pages.
Recently, weโve noticed that some validator nodes on polkadot, encounter a โallocator failed to allocate memoryโ error around the time when the staking election (phragmen) is being computed. Recall that this computation is happening in an offchain worker thread. Nonetheless, in the current implementation, the offchain worker thread, which itself is executed in WASM, uses the same WASM environment as the canonical runtime, and therefore has limited memory. To prevent the situation where no validator submits an election solution, the amount of memory accessible to the offchain worker environment should be increased.
Note that ideally, this change should only affect the offchain worker thread, and not the main runtime. But as mentioned, currently they share the same configurations. A long term solution is to separate these configurations and only increase the amount of memory that is accessible to the offchain worker (PR). But, since this is not readily possible, we opt to propose increasing the overall WASM runtime memory pages, which affects both block execution and offchain worker. We expect this decision to have no notable effect on the main runtimeโs progress and execution.
The amount of memory available to WASM is determined in the number of โpages of memoryโ that can be allocated in the called, aka. โHeap pagesโ. This value lives on-chain, and you can inspect it similar to other well-known-keys via โ:heappagesโ. Currently, no value is set there and a default of 1024 is used.
More info can be found HERE.
This proposal is a temporary solution, Kian from Parity is working on a permanent fix here.
UPDATE: Please be so kind to reject this proposal, the team has included the heap pages increase on a client upgrade and this seems to be the best way to approach the issue.
Discover similar proposals