[Runtime] RT2600 schedule

Development Runtime upgrades
,
1

We are planning to release Runtime 2600 in ALL network(s) following the schedule below:
Alphanet: 2023-11-13T23:00:00Z
Moonriver: 2023-11-27T23:00:00Z
Moonbeam: 2023-12-11T23:00:00Z

This runtime upgrade includes several breaking changes.
See the release note for more details: https://github.com/PureStake/moonbeam/releases

5 Likes
2

great news :star_struck: :+1:
wait for it

3

Update: There was a potential issue in the migration for orbiter bonds so RT2601 will be released to all networks instead.

1 Like
4

On-chain proposal for Moonriver:
https://apps.moonbeam.network/moonriver/referendum/40

2 Likes
5

Runtime 2601 was released on November 13, 2023 and contains many improvements targeting a variety of community stakeholders.

Community

  • Governance

When a referendum is created, there is a limited amount of time for a decision deposit to be placed before the referendum “times out” and the submission deposit cannot be refunded. This timeout has been extended from 14 days to 21 days to give community members more time to source the needed MOVR/GLMR for a decision deposit.

Collators

  • Ability to Mark Inactive Collators as “Offline”

A new chain parameter (enableMarkingOffline) has been added and can be enabled/disabled via governance. Once enabled, it allows anyone to flag an inactive collator as offline by calling parachainStaking.notifyInactiveCollator. If the collator is truly inactive (it did not produce any blocks in the last staking round), then it is flagged as offline. This feature allows community members to take action if there are collators in the active set that have gone offline and are disrupting block production.

  • Ensure Orbiter Rewards are Consistent

Addresses an issue where newer orbiters were receiving higher rewards. See forum post for details.

  • Update bootnodes list

Reflects offboarding of OnFinality and onboarding of UnitedBloc bootnodes.

Developers

  • Enablement of a Storage Limit per Gas (MBIP-5) on Moonriver

This change is to ensure that the Storage of the networks grow in a sustainable way by limiting the amount of storage that can be included in a given block. See forum post for details.

MBIP-5 will be enabled on Moonbeam in RT2700.

  • Enable Transactor Precompile v3

Allows to send XCM messages to other chains via a solidity interface. This version supports XCM V3 and optimizes use of funds toward fees.

  • Ability to Transfer Tokens to AssetHub that are not “sufficient”

The initial MRL (Moonbeam Routed Liquidity) implementations (eg. HydraDX) focused on routing assets from Ethereum mainnet to parachains through Moonbeam. Since then, some parachain teams have expressed interest in routing in the opposite direction - that is, routing Polkadot native assets through MRL to other ecosystems. This change allows Moonbeam Routed Liquidity to work with Polkadot Native assets (see the blog post Moonbeam Routed Liquidity).

  • Long term fix for the “suicided” contracts

Addresses of suicided contracts (contracts that were destroyed by self-destruct) are tracked in storage. RT2700 will provide a precompile to be able to delete the actual storage that has been left behind.

RT2601 contains numerous other bug fixes and improvements to the core protocol, many of which originated from community requests and the Moonbeam Foundation’s bug bounty program. The Moonbeam Foundation would like to thank community members who have taken the time to report bugs and suggested improvements. This can be done using request.moonbeam.network.

6 Likes
6

thanks a lot for the detailled feature breakdown :pray:

2 Likes
7

thanks for the detailed layout of the runtime @aaron.mbf !

2 Likes
8

A bug has been discovered in RT2601 on Moonbase Alpha. Several members of the core development team are still investigating but the recommendation is that a hotfix (RT2602) should be prepared and be rolled out to all networks instead of RT2601.

There are 2 days left for deciding of MR40 (Upgrade Moonriver to RT2601).
The Moonriver and Moonbeam Technical Committee has agreed that MR40 should be canceled while awaiting the RT2602 build.

MR42 has been created to cancel MR40.

The Technical Committee is recommending the community vote “Aye” to MR42 and “Nay” to MR40 in case the Cancel does not succeed for whatever reason.

More details will follow regarding RT2602 and the updated rollout schedule …

6 Likes
9

UPDATE ON SCHEDULE AND RELATED BUG

Upon further investigation of the bug I mentioned above, it’s been determined that the existing runtimes (RT2501) of the Moonriver and Moonbeam networks are also impacted by a similar issue and this has increased the urgency in terms of a fix.

The OpenGov Technical Committee was notified regarding the situation and assessed various options. Based on the recommendations of the Foundation in consultation with core developers investigating the issue, the OpenGov Technical Committee has approved whitelisting a runtime upgrade to support an accelerated rollout plan of an RT2602 build and a 0.34.1 client.

The rollout of RT2602 would roughly follow this schedule (assuming enough support is achieved):

Alphanet: November 29, 16:00 UTC

Moonriver: November 29, 19:00 UTC

Moonbeam: November 30, 01:00 UTC

The referenda are up for voting how:
MR43 - Upgrade Moonriver to RT2602 via Whitelist Track

MB33 - Upgrade Moonbeam to RT2602 via Whitelist Track

Further details regarding the nature of this issue will be shared at a later date.

4 Likes
10

Thanks for the update aaron, thanks that the error was finds early

1 Like
11

Moonriver has been upgraded to RT2602 and is producing blocks.

4 Likes
12

Moonbeam has been upgraded to RT2602 and is producing blocks

1 Like
13

FOLLOW-UP ON RT2602 AND RELATED BUG

On November 22, 2023, a Moonbeam ecosystem team reported a critical bug through private channels impacting runtime 2600.

The issue was promptly investigated by members of the core development team who confirmed the existence of the bug and a potential exploit. Further investigation found that the bug was present in previous runtimes as well.

As described above, the OpenGov Technical Committee was notified regarding the situation and approved whitelisting a runtime upgrade to support an accelerated rollout plan of an RT2602 build and a 0.34.1 client.

As of November 30th, all networks were successfully upgraded to RT2602.

Since then, details of the discovered bug were shared with the Frontier Advisory Group who then contacted other projects that may have been affected. After conferring with those projects, it was determined that they were not at risk due to this particular bug and the patch has been committed to Moonbeam’s public repos. On January 2, 2024, details of the bug and the patch were published to github here.

Now that the responsible disclosure process has been completed, it is safe to share the nature of the issue itself.

Summary:

Under certain circumstances, when a smart contract is deployed with marginally insufficient gas and it fails due to an OutofGas error, EVM events from the transactions within its constructor are still emitted.

Impact:

Although the state of the chain is properly reverted following the failure, off-chain components that rely on the EVM events to track state changes (eg. token transfers, etc) may behave incorrectly due to the processing of erroneously sent events.

An attacker could craft a smart contract in a way that would fail to deploy following the execution of its constructor and include a set of transactions in the constructor designed to mislead off-chain components that rely on EVM events in order to achieve some sort of financial gain.

Resolution:

After some investigation, it was determined that while the conditions leading to triggering the bug were relatively rare, the enablement of MBIP-5 increased the likelihood of it occurring, as MBIP-5 marginally increased the gas requirements of some specific smart contract interactions. Consequently, tools that do not rely on RPC-based gas estimations would use their own gas estimation models, which in specific scenarios might result in a value just below the actual value required for proper execution. Therefore, there was a reasonable chance that the issue could have been discovered by a bad actor.

It was further determined that the risk of the patch was relatively low while the impact of an exploit could be relatively high.For this reason, the OpenGov Technical Committee voted in favor of an accelerated rollout of RT2602 for both Moonbeam and Moonriver to address the issue.

4 Likes