Runtime Upgrade 1200: London Upgrade Support, Staking Changes and More

Moonbeam/Moonriver thrives on being the most Ethereum-compatible parachainGo to page https://moonbeam.network/education/what-is-a-parachain/ in the Polkadot/Kusama Ecosystem. That is why the team has pushed to bring features such as unified accountsGo to page https://docs.moonbeam.network/learn/core-concepts/unified-accounts/, subscription to eventsGo to page https://docs.moonbeam.network/builders/tools/pubsub/, support for the tracing RPCGo to page https://docs.moonbeam.network/builders/tools/debug-trace/, among other features.

The team’s goal is to stay as close as possible to Ethereum, to provide a frictionless environment for projects and be the easiest on-ramp to tap into the Polkadot/Kusama ecosystems.

As part of this effort, the latest runtime upgrade (1200) brings significant changes to Moonbeam’s Ethereum compatibility layer.Go to page https://github.com/moonbeam-foundation/frontier The runtime upgrade is tied to the new client (v0.19) as well, and includes, among other things, the first steps to support EIP-1559.

This blogpost briefly goes through the main technical changes of the 1200 runtime upgrade

London Upgrade Support

On 5th August 2021, Ethereum introduced the London hard fork, dubbed EIP-1559, even though it includes other EIPs. The main reasoning behind this hard fork, was the introduction of a new transaction pricing mechanism that includes fixed-per-block fee that is burned and dynamically-sized blocks to deal with transient congestions of the network.

The Moonbeam 1200 runtime upgrade adds support for the following EIPs (all part of the London hard fork):

• EIP-1559Go to page https://eips.ethereum.org/EIPS/eip-1559 – a new transaction pricing mechanism
• EIP-3198Go to page https://eips.ethereum.org/EIPS/eip-3198 – BASEFEE opcode, which gives the EVM access to the block’s base fee
• EIP-3529Go to page https://eips.ethereum.org/EIPS/eip-3529 – reduction in refunds when clearing storage
• EIP-3541Go to page https://eips.ethereum.org/EIPS/eip-3541 – reject new contracts starting with 0xEF byte

EIP-1559: A New Fee Mechanism

EIP-1559 was introduced to shift the fee market model from a first-price auction, to a base-fee plus tipping mechanism. The goal of this EIP was not to reduce gas price, but to create a more predictable and transparent fee structure for users. Furthermore, wallets that support EIP-1559, will provide users with better transaction cost estimates, improving the overall user experience.

To be able to support the EIP-1559 fees mechanism, different upgrades needed to be done in the runtime (WASM based logic with the core state transition functions) and the client (networking and communication layer with/around the runtime and node).

To fully support EIP-1559, the 1200 runtime upgrade adds support for the following EIPs:

• EIP-2718Go to page https://github.com/ethereum/EIPs/blob/master/EIPS/eip-2718.md – introduces typed transactions. The new typed transactions are still RLP-encoded, but a byte is prepended to specify the transaction type. If this byte is not included, it is a legacy transaction, so there is backward compatibility
• EIP-2930Go to page https://github.com/ethereum/EIPs/blob/master/EIPS/eip-2930.md – introduces transaction type 0x01, with optional access list to reduce for accessing an account or storage slot.
• EIP-1559Go to page https://github.com/ethereum/EIPs/blob/master/EIPS/eip-1559.md – introduces transaction type 0x02, with the necessary updates for the new fee model mechanism. It builds on top of the previous transaction type

Nevertheless, runtime upgrade 1200 only introduces the building blocks for the implementation of EIP-1559 fee mechanism, which is planned in a future runtime upgrade. The current implementation has he following core differences:

• The base fee is set to the min gas price of the network, and does not dynamically change in the current implementation. That is, 100 Gwei for Moonbeam, 1 Gwei for Moonriver, and 1 Gwei for Moonbase Alpha. The eth_gasPrice will return this value
• Block size will continue as before, fixed to 15M gas per block, and roughly 12.95M gas for a single transaction. There is no dynamic block size, as this is determined by the block execution time allowed by the relay chain
• Anything above the base fee will be refunded to the sender of the transaction
• The tip is what is used to prioritize the transactions. In the current implementation, this is not given to the block author, 80% is burned and 20% goes to the Treasury. This might change in the future

Ethereum API Changes

The introduction of the first building blocks for EIP-1559 also includes some changes in Moonbeam’s Ethereum API. The new RPCs and properties are part of the EIPs mentioned before, and can be summarized in the following:

• eth_feeHistory – new rpc endpoint which returns a collection of historical gas information for up to 1024 blocks
• baseFeePerGas – new block property. Base fee per gas used for a given block. Currently, it is the minimum gas price for each network. eth_gasPrice will return this value
• effectiveGasPrice – new property inside the transaction receipt. Gas priced being used for the transaction
• accessList – new transaction object property, part of EIP-2930Go to page https://github.com/ethereum/EIPs/blob/master/EIPS/eip-2930.md. An array of type [ [ { 20 bytes }, [ { 32 bytes }…] ] … ], storing the contract address and the storage keys
• maxFeePerGas – new transaction object property. Defines how much base fee the transaction is allowed to pay
• maxPriorityFeePerGas – new transaction object property. Correspond to the “tip” to prioritize transactions. Currently, 80% is burned and 20% goes to the Treasury, although this might change in the future
• type – new transaction object property. Type of the transaction: 0x0 for legacy, 0x1 for EIP-2930Go to page https://github.com/ethereum/EIPs/blob/master/EIPS/eip-2930.md, and 0x2 for EIP-1559Go to page https://github.com/ethereum/EIPs/blob/master/EIPS/eip-1559.md

Staking Query Changes

Although support for EIP-1559 was the main topic of runtime upgrade 1200, there were also some changes to the parachain staking pallet (parachainStaking). These changes needed to be done mainly to reduce the size of the CandidateState, and therefore, the size of the Proof-of-ValidityGo to page https://wiki.polkadot.network/docs/glossary#proof-of-validity (PoV). The PoV needs to be carefully managed because if it becomes too large, the parachain may stall. Therefore, it was split into three separate storage items: candidateInfo, topDelegations and bottomDelegations. The top delegations refer to those delegations that are considered active, meaning that they are in the top N in terms of stake. Where N is the maximum number of delegates per candidate (currently 300 for all networks). The bottom delegations refer to those who are out of the active delegation set. It maxes out at 50 bottom delegators per candidate. If all bottom delegations are filled, a new delegation will kick the lowest bottom delegator (in terms of stake) out of the set, revoking the delegation instantly.

Note: all delegations that are outside of the 50 bottom delegations (per candidate) will be automatically and instantly revoked. Any new delegation that is higher than the lowest bottom delegation will result in that lowest bottom delegation being instantly revoked

The chain state staking elements that changed are the following:

• candidateState – it is now deprecated and won’t return any date. It is replaced by the next three items
• candidateInfo – returns the candidate metadata:
  • bond: bond amount
  • delegationCount: total number of delegations for a given candidate
  • totalCounted: sum of the bond and the top delegations
  • lowestTopDelegationAmount: the lowest top delegation amount
  • highestBottomDelegationAmount: the highest bottom delegation amount
  • lowestBottomDelegationAmount: the lowest bottom delegation amount
  • topCapacity: capacity status for top delegations
  • bottomCapacity: capacity status for bottom delegations
  • request: pending request to decrease candidate self bond at any given time (the maximum is 1)
  • status: current status of the candidate (active, idle or leaving)
• topDelegations – returns the active delegations for a given candidate. These are the top N delegations, where N is the maximum number of delegates per candidate
• bottomDelegations – returns the inactive delegations for a given candidate. These are the delegations that are part of the top delegations in terms of stake
• maxDelegatorsPerCandidate – deprecated in favor of maxTopDelegationsPerCandidate
• maxTopDelegationsPerCandidate – returns the maximum number of active delegates per candidate. For example, this is currently set to 300 in all Moonbeam-based networks
• maxBottomDelegationsPerCandidate – returns the maximum number of bottom delegations. For example this is currently set to 50 in all Moonbeam-based networks

In addition, the following events were modified:

• CandidateWentOffline – now only provides the candidate address
• CandidateBackOnline – now only provides the candidate address

Also, the following event was added:

• DelegationKicked – emitted when the lowest bottom delegation is kicked out of the delegations list. This happens when a new delegator enters with a stake higher than the lowestBottomDelegationAmount

XCM Related Changes

XCM was introduced in Moonriver on runtime upgrade 1102. Since then, at the time of writing, there are more than 8000 KSM and 390000 RMRK on Moonriver as xcKSM and xcRMRK. These XC-20 assetsGo to page https://moonbeam.network/blog/introducing-xc-20s/ can benefit from Kusama’s interoperability, while enjoying a familiar ERC-20 interface on Moonriver, so they can be easily integrated into EVM dApps. For example, we’ve seen both xcKSM and xcRMRK listed on DEXs.

Runtime upgrade 1200 brings the following XCM-related changes:

• Enable XCM on MoonbeamGo to page https://github.com/moonbeam-foundation/moonbeam/pull/1183 – XCM is still not available on Polkadot. Nevertheless, this means that Moonbeam is XCM-ready once the feature is enabled at a relay chain level
• Support for new Statemine asset representationGo to page https://github.com/moonbeam-foundation/moonbeam/pull/1159 – adds support for Statemine’s multi-location asset representation that will go live in the near future. This will not enable users still to send assets back to Statemine

The AssetManager pallet also has some types related changes for query functions:

• assetIdUnitsPerSecond – it is now deprecated in favor of asset_type_units_per_second
• assetTypeUnitsPerSecond – returns the units per second of execution charged to execute a related XCM message. Similar to the deprecated function but now needs the assetType and not the assetID (as before). This requires knowing the multi-location of the asset

In the same pallet, the following events was modified:

• UnitsPerSecondChanged – now returns the assetType instead of the assetId

In the same pallet, the following extrinsic were added/modified:

• setAssetUnitsPerSecond – modified so now you need to provide the assetType instead of the assetId
• changeExistingAssetType – new extrinsic which allows to change the assetId associated to an assetType

Other Changes

Apart from usual stability and performance updates, the runtime upgrade 1200 also brings the following notable changes:

• AuthorMapping precompile – this precompiled contract is the missing piece for collators to be able to do all the necessary actions through the Ethereum API. This means that collators could host their candidate account in a Ledger/Trezor device. Available in all Moonbeam-based networks
• Native token ERC-20 interface – this precompiled contract was previously introduced in Moonbase Alpha and Moonriver. Runtime upgrade 1200 also adds new dummy deposit and withdraw functions. These were included so that the precompile contract can be backward compatible with dApps that expect those functions. The deposit function will just deposit the amount to the sender of the transaction and emit the necessary event. The withdraw function will just emit the event
• Democracy precompile – this precompiled contract was previously introduced in Moonbase Alpha. Runtime upgrade 1200 also adds it to Moonriver. It enables network participants to engage in democracy referenda using the Ethereum API. Exciting news will follow…