root

Abstract
Moonbeam&rsquo;s current lease period on the Polkadot network will expire in October 2023. In June 2023, the Moonbeam Foundation successfully secured a new parachain slot on Polkadot covering lease periods 13 through 20.
This proposal is a necessary step to extending Moonbeam&rsquo;s Polkadot lease period through June 2025 by executing a &ldquo;swap&rdquo; of lease periods.
If the swap is not completed before October 2023, Moonbeam will not occupy an active parachain slot and would stop producing blocks.
Details
The lease for periods 13 through 20 is currently occupied by &ldquo;Moonelement&rdquo; with parachain ID 3342, a dummy parachain runtime created by the Moonbeam team.
In order to complete a lease swap between Moonbeam (parachain 2004) and Moonelement (parachain 3342), a &ldquo;handshake&rdquo; must be completed whereby both parachains authorize the lease swap.
From the Moonbeam side, <a href="https://forum.moonbeam.network/t/proposal-mb11-proposal-to-swap-lease-slots-with-parachain-id-3342/1165/">Moonbeam OpenGov Referendum 11</a> is expected to be confirmed in approximately 1 day (September 6, 2023). The passage of this referendum will cause an XCM message to be sent to the Polkadot relay chain calling the registrar.swap extrinsic. This extrinsic will authorize the swap from the Moonbeam side.
To complete the &ldquo;swap&rdquo; process, a similar swap authorization will be required to be made on behalf of the Moonelement parachain (ID 3342). The Moonbeam team had planned to start the Moonelement parachain and initiate a similar XCM message to be sent to the relay chain.
Unfortunately, there was a misconfiguration in the genesis head that was submitted along with the WASM when the parachain was initially registered. The Moonbeam technical team has determined that starting Moonelement will not be possible.
For this reason, the Moonbeam Foundation has created Polkadot OpenGov Referendum 139 which, when passed, will execute the registrar.swap extrinsic on behalf of the Moonelement parachain.
Using &ldquo;Chopsticks&rdquo;, the Moonbeam team has verified that the parachains will successfully swap leases once both the Moonbeam and Polkadot governance motions are passed and executed.
Once the parachains swap leases, the Moonbeam Network will be able to continue operation without interruption for the remainder of the full lease period (approximately 96 weeks from August 1, 2023).
Links
<ul>
<li><a href="https://wiki.polkadot.network/docs/learn-auction#parachain-lease-extension">Parachain Lease Extension (Polkadot Wiki)</a></li>
<li><a href="https://moonbeam.foundation/news/moonbeam-new-parachain-slot-lease/">Successful Auction Bid Announcement</a></li>
</ul>

Deciding

Moonbeam: Swap Leases with Parachain 3342

This is a referendumV2 whose proposer address (13Z41Vh5LTZhXGN6kXGBpfw3Bpt3PYMyM4rKr8hL3wFeadK4) is shown in on-chain info below. Only this user can edit this description and the title. If you own this account, login and tell us more about your proposal.

TimedOut

Untitled

Please check our post <a href="https://medium.com/nodle-io/latest-parachain-upgrade-what-everyone-should-know-9d5563e97a70">here</a> describing the incident and its reasons. In this document we will be focused on a detailed description of the steps taken to resolve the issue.
TL;DR
The Nodle Parachain is bricked after its last upgrade failed. This proposal proposes to use the forceSetCode functionality on Polkadot to ensure the prompt restart of the parachain.
Solution
The solution presented below intends to maintain the existing Parachain state, and not require to revert previously approved transactions which would break finality guarantees.
It appears everything in the recent upgrade was sound with all state transitions being correct and intended. However, the migration code associated with the upgrade is taking too long and caused the proof of verification to grow beyond what the relay chain validators tolerates. Because the migration happens right when the runtime is upgraded, this causes the parachain to halt block production as the next block would always be rejected by the Polkadot validators. As such, the head of the parachain did not progress to any undesired state, and thus can be reused.
This means that it should be possible to unbrick the parachain by force setting the current code to a new runtime that is very similar to the stored runtime. As such, <a href="https://github.com/NodleCode/chain/releases/tag/2.2.2-hotfix">a new runtime has been prepared</a> with the changes below:
<ul>
<li>Identical spec version than initially deployed</li>
<li>Keeps the uniques pallet at the same storage prefix</li>
<li>Remove the migration</li>
<li>Remove the new pallet associated to the migration</li>
</ul>
When this code is forced on the relay chain then collators can use the --wasm-runtime-overrides flag to force their nodes to use the appropriate wasm code that is recognized by the relay chain.
Testing and verification
Here are the steps we took to test this proposal:
<ol>
<li>We used polkadot-launch and ran a local rococo relay chain with a few validators and a collator of our eden-dev parachain. All with fresh states starting from scratch. For the relay chain binary we used Polkadot-0.9.42 and for our parachain we used nodle-2.0.30 which is the previously published image for our nodes and contains the exact same runtime as it was on our chain right before the problematic upgrade.</li>
<li>We made runtime wasm out of <a href="https://github.com/NodleCode/chain/blob/sample-failure/runtimes/eden/src/migrations.rs#L25-L26">code</a> that could easily induce the heavy migration step for a local test. We selected the integration of an infinite loop as the fastest way to reproduce the conditions of the issue.</li>
<li>We upgraded the local collators runtime with the runtime wasm which had the intentional failure in its migration. We noticed the node indeed stopped producing blocks with the exact same message as we had seen on our collator &ldquo;Discarding proposal &hellip;took too long&ldquo;. This confirms correct reproduction of the current issue.</li>
<li>We then used Sudo on the local rococo relay chain and called forceSetCurrentCode with the <a href="https://github.com/NodleCode/chain/releases/tag/2.2.2-hotfix">runtime wasm</a> that we are going to use in our proposal. Let&rsquo;s refer to that as the good runtime. We already have discussed the idea behind this code change in the Solution section above.</li>
<li>We then stopped the collator and re-ran it using --wasm-runtime-overrides and setting it to the folder that contained the good runtime. The storage of the collator was maintained and no modification was made there. After the restart the collator started producing blocks and the relay chain backed and included them.</li>
</ol>
Proposal Preimage
Our proposal is paras -&gt; forceSetCurrentCode(para: 2026, newCode: [our good runtime], leading to the preimage hash of &ldquo;0xbdeb173184c3a932473b7921c0feb233900bbe9228c54dc346239a93b186e9cc&rdquo; and preimage length of 1216833 as shown in the following screenshot:
<img src="https://i.ibb.co/p4jJth8/Screenshot-2023-08-24-at-2-05-52-PM.png" alt="" width="640" height="320" />
Prevention Strategy
We intend to work with the Polkadot community to improve existing testing tools to detect similar issues to the one being fixed today. Namely, we would like to extend try-runtime to at least show if the PoV for a runtime upgrade is growing beyond the 5MB limit that is set for validators. Alternatively, this could also take the form of an independent test tool as well.
Regardless of what tool is developed, we will enforce the benchmarking of any migration code in our upgrade process.
Additionally, we would like to investigate whether some patches could be contributed to the Polkadot codebase to optimize for the liveness of parachains by falling back to the last known good runtime in case of upgrade or migration failures. Because this sounds like a much bigger effort given our team expertise, we will need further discussions on this topic.

Executed

Unbrick Nodle

**Proponent: [Women in Blockchain Canada]
Date: [28.07.2023]
Requested DOT: [Approximate amount 35,000 USD - 6,686 - on July 29th ]
Short description: [Artificial Intelligence for security on a network level ]
Project Category/Type: Software Development - Security
Previous treasury proposals: Education https://polkadot.polkassembly.io/motion/206
**


Context of the proposal 
Our goal is to first build a proof-of-concept machine learning tool that conducts research and analysis on the network level which is able to find anomalies and enable early warning systems for security issues that start occurring. We would utilize adaptive A.I. and unsupervised machine learning algorithms to gather and process the incoming data in real time. Our system would ascertain baseline behavior and then auto-detect any changes that deviate from it in order to assess whether a warning signal is warranted. Once the system would identify real issues, we would create an early warning system that would flag the issues as they start occurring to those in the Polkadot network. This following document contains the background, rationale and development steps elaborating on reaching we will conduct in order to develop the PoC machine learning tool.

Full proposal link:
https://docs.google.com/document/d/1GBc8xCEFfxA_hGNCsmznwjgZ3YWtA4wislE6VlNIUJA/edit

Project Team
We have a distributed team of frontend and backend developers along with a project manager. Our lead developer handles the primary workload as well as one full time developer working under him. The team has a combined 60+ years of experience with web and application integration. Our team is currently working on a web3 enabled website that uses the learn and earn model for the Stellar Foundation (Learnweb3.network). 
Please note that Danny Kovach has developed his own artificial intelligence as well as has over a decade of experience working in the field for both NASA and Citi bank. Please checkout https://github.com/quant-guy and https://github.com/0x0000d3ad for his work.
This is Daniel Kovach’s academic work.
https://www.researchgate.net/profile/Daniel-Kovach


Proposal: Artificial Intelligence for security monitoring on a network level 

(Same as on Kusama https://kusama.polkassembly.io/referenda/173)

# Fix HostConfiguration (maxCodeSize to 3 MiB)

The current Polkadot `HostConfiguration` does not fulfill all assumptions about its consistency. This proposal aims at correcting that by modifying the on-chain config.

## Problem

 The `HostConfiguration::consistency_check` function asserts that the on-chain [`max_code_size`](https://github.com/paritytech/polkadot/blob/v0.9.41/runtime/parachains/src/configuration.rs#L376) is never larger than `MAX_CODE_SIZE`. This is violated on Polkadot since the concrete `max_code_size` on-chain is 10 MiB and `MAX_CODE_SIZE` is only [3 MiB](https://github.com/paritytech/polkadot/blob/v0.9.41/primitives/src/v2/mod.rs#L331).  
 You can verify this by querying [PolkadotJS](https://polkadot.js.org/apps/#/js):
 
```js
let config = await api.query.configuration.activeConfig();
console.log(config.maxCodeSize / (1024*1024), "MiB");
// Prints 10 MiB
```

It is neccecary to correct this since otherwise the `consistency_check` will stay a No-OP with the [assumption](https://github.com/paritytech/polkadot/blob/v0.9.41/runtime/parachains/src/configuration.rs#L1324): "You cannot break something that is already broken".


## Proposal

Set the on-chain `max_code_size` back to a sane value of 3 MiB. A larger value is not expected to work due to networking restrictions. Related discussions about this are in [polkadot/#7108](https://github.com/paritytech/polkadot/issues/7108) and [polkadot/#7105](https://github.com/paritytech/polkadot/issues/7105).

## Impact on Para*s

Parachain/Parathread teams should check that all queued runtime upgrade have a size of at most 3 MiB (the `Runtime Size` as reported by `srtool`). A sweep across [all parachains](https://github.com/paritytech/polkadot/issues/7108#issuecomment-1516220831) showed that the largest is currently 1.7 MiB, that is about 57% of the new limit. So no problem here.

## Impact on Developers

\-

[0] Origin: Root