[Runtime] RT3100 Schedule

We are planning to release Runtime 3100 in ALL network(s) following the schedule below:
Alphanet: 2024-07-28T22:00:00Z
Moonriver: 2024-08-18T22:00:00Z
Moonbeam: 2024-09-01T22:00:00Z

This runtime upgrade includes one breaking change.

  • New process of foreign assets creation (Moonbase)

The v0.39.0 client includes one breaking change.

  • Upgrade to polkadot sdk v1.11.0 (new host function ext_storage_proof_size_storage_proof_size_version_1 for PoV reclaim)

Note: The client cannot be downgraded after runtime version >= 3100 is enacted.

See the release note for more details:

Runtime: Release Runtime 3100 · moonbeam-foundation/moonbeam · GitHub
Recommended Client: v0.39.0
Minimum Client: v0.39.0
Tracing: moonbeamfoundation/moonbeam-tracing:v0.39.0-3100-28da

3 Likes

Upgrade Recap

Here is a summary of the Runtime Upgrade 3100, including several key changes within the ecosystem. Runtime Upgrade consists of different feature sets depending on the network we’re updating. Below, you will find the detailed summary split between the destination environments:

  • [All networks]
    • Passkey support: support for the passkey cryptographic signatures
    • Update to Polkdadot-SDK 1.11.0
    • Technical support for Snowbridge
    • Runtime API for XCM fee estimation
  • [Moonbase Alpha]
    • Introduce native EVM foreign assets
      • changes the process to manage XCM derivative assets
  • [Moonbeam]
    • Increase block gas limit from 15 mln to 30 mln
  • [Moonriver]
    • Increase block gas limit from 30 mln to 60 mln
  • Several Bug Fixes

Passkey support

It’s the first stage enabling the native use of Passkeys in projects, especially when implementing account abstraction like Smart Wallets.

Polkadot compatibility

New host function for PoV reclaim

Audience: Collators, Node operators

Introduces a new host function ext_storage_proof_size_storage_proof_size_version_1 for PoV reclaim

Prevent accidental change of network key for active authorities

Audience: Node operators

For all authority nodes, the node binary now enforces the presence of a network key, instead of auto-generating when it is absent.

Scaling Moonriver and Moonbeam

Async Backing: Increase the block gas limit

Audience: Core Developers, DappDevelopers

Parameters related to gas limits will be increased by a factor of 2 on Moonriver and Moonbeam. Therefore, the EVM max gas limit is increased from 15M to 30M on Moonbeam and from 30M to 60M on Moonriver. This, again, was made possible by the adoption of Asynchronous Backing.

When considering a simple transaction such as an ERC-20 transfer, the throughput of Moonriver and Moonbeam will increase by 2x.

Pending a successful deployment on Moonbeam, gas parameters will be doubled again in a subsequent release, increasing the overall throughput to 8x. Moonbeam’s gas parameters will also be augmented in release RT3200 by a factor of 2.

Moonbase Alpha continues to run with a 60M gas limit.

Ethereum Compatibility

A new way of creating Ethereum-compatible foreign assets

Audience: Dapp Developers

Runtime 3100 ensures Moonbean alpha is fully compatible with the Ethereum tools for testing and verifying foreign assets. This will allow app developers to use all the tools available for Solidity.

Technical details

A new pallet, “pallet-moonbeam-foreign-assets”, has been added.

The purpose of this new pallet is to manage XCM derivative assets on Moonbeam through EVM smart contracts.

Before this implementation, XCM derivatives assets (aka “foreign assets”) were managed by the pallet asset manager and the pallet substrate pallet “pallet-asset.” The long-term goal is to remove these two pallets from moon$ runtimes (asset-manager and pallet-asset), but before doing so, we will first have to migrate all existing foreign assets in production.

This is only the plan’s first stage: creating future foreign assets according to the new design. Subsequent PRs will manage the migration of existing foreign assets and the removal of the two depreciated pallets.

​​Note

Creating foreign assets requires a new process; the current one will not work anymore.

Native foreign assets metadata are immutable and cannot be changed once they are created (the legacy foreign assets implementation allowed changing the metadata)

X-Chain Capabilities

Technical support for Snowbridge

Audience: Dapp Developers

Runtime 3100 introduces the first stage support for Snowbridge. Snowbridge is a bridge between Ethereum and the Polkdadot ecosystem. In a word, it’s a parachain, BridgeHub, that connects to AssetHub

The objective for Runtime 3100 was to verify that we can accept assets coming from BridgeHub (through AssetHub).

Runtime API for XCM fee estimation

Audience: Dapp Developers

A new runtime API is introduced, the XcmDryRunApi, that, given an extrinsic or an XCM program, returns its effects:

  • Execution result
  • Local XCM (in the case of an extrinsic)
  • Forwarded XCMs
  • List of events

This API can be used alone for dry-running purposes, double-checking, or testing, but it mainly shines when used in conjunction with the XcmPaymentApi. UIs can use these two APIs to estimate transfers.

Other

Several Bug Fixes

Audience: Dapp Developers

  • Solve incompatibility in rollbacks for EVM calls inside substrate transactions.
4 Likes

MR60 is up for a vote on Moonriver.

Vote using the official dapp or Polkassembly .

3 Likes

MR64 is up for a vote on Moonbeam.

Vote using the official dapp or Polkassembly .

5 Likes

Moonriver upgrade enacted at block 7829527

3 Likes

Moonbeam upgrade enacted at block 7303601

3 Likes

The Moonbeam Foundation has proposed a whitelisting of a runtime upgrade to RT3102 in order to address a few issues introduced in RT3100 related to fees for XCM transfers and gas estimation. In addition, RT3102 will increase the gas per block from 30M to 60M.

A majority of the members of the Moonbeam OpenGov Technical Committee have approved the whitelisting of the proposal.

Community members are therefore invited to vote on MB69 to approve or reject the authorization to upgrade to RT3102.

If approved, the upgrade will be enacted at approximately 1 PM UTC on Monday, September 23.

1 Like

hey Aaron, just to clarify - does the same issue persist on Moonriver, or is it specific to Moonbeam? from your message, I understand that the new runtime has already been proposed for Moonbeam, but it doesn’t seem to be the case for Moonriver. there’s an active proposal on Moonriver, but it lacks proper info: Moonbeam Dapps

1 Like

Hey @turrizt - so some of these issues are technically also present on Moonriver but folks haven’t run into them because it’s on a bit of a use case by use case basis. That is, we’ve not had complaints.

However, they will be addressed in 3201 which @piotrmbf will be posting about shortly.

1 Like

To follow the official communication scheme:

Runtime 3102 has been published, and it is planned to go live on Moonbeam on September 23, 2024, at approximately 1 pm UTC.

MB69 is up for vote on Moonbeam to authorize the upgrade.

Vote using the official dapp or Polkassembly.

Changelog

  • Set the block size to 60mln gas (#2921)
  • Divide ref time XCM fees by four (#2929)
    • Restore XCM fee costs to values equivalent to the pre-block gas limit increase
  • Propagate OutOfGas to outer call if caused by proof size check or MBIP5 (#2950)
    • Avoid low gas estimation for transactions that have high PoV or MBIP5 costs
1 Like

A runtime hotfix, RT3102, was explicitly released for Moonbeam to address the gas estimation issue. It has been reported for Moonbeam specifically that in the case of more complex tasks, smart contract calls users experienced out-of-gass errors. We have refined the logic to measure the contract call more precisely and thus provide a more accurate gas estimation. This should lead to the user being able to pay and execute their calls successfully.

RT3102 also includes one feature to adjust the gas limit from 30M to 60M so we can complete scaling our infrastructure earlier than planned. A side effect of increasing the block gas limit is that the XCM fees have increased proportionally. Thus, to keep the XCM fees the same, we divide them by a factor of 4.

We appreciate your understanding and continued support of the Moonbeam network.

4 Likes