In speaking with various service providers and stake holders, it sounds as though we’ve reached the point where it’s becoming challenging to use some of their operational tools, etc.
It is being proposed that we shorten the delay between Moonriver and Moonbeam to so that RT2302 is deployed to Moonbeam approximately 24 hours after Moonriver.
Moonriver Referendum is up:
Full support - this is trash and impacting the network for teams looking to do legit applications
I am in favor of this proposal because I have observed that numerous community members txs are getting stuck, requiring them to wait for hours, or even days. this is because many of them do not comprehend the need to speed up the gas or use aggressive gas settings
I fully support the proposal.
I have updated the post to propose that RT2302 would be deployed to Moonbeam 1 day following Moonriver and invite community members to comment on this.
I’m considering potential issues that may arise due to the varying network loads between Moonriver and Moonbeam. I’m uncertain whether testing something on Moonriver for one day would suffice to ensure everything is working correctly. Your thoughts and opinions are welcome
Upgrade on Moonriver has been enacted and will apply in about 20 minutes or so.
I understand your concern about the security of it.
The current proposed Runtime has been tested carefully like all the previous ones (which includes lot of rigourous tests but also deployment on multiple internal networks for each runtime).
We usually have a delay to ensure new features are well understood by the developers on Moonriver and to gather feedback before moving to Moonbeam.
For this runtime, it doesn’t include a lot of features impacting the developers. Some of them impact the community, like the dynamic gas fee, but this feature was already deployed to Alphanet 2 releases ago, and to Moonriver 1 release ago, so it was tested there.
No testing is good enough, not enough time is sufficient to get a 100% guarantee but we will never sacrifice the security of the chain for any other aspect.
I hope this answers your concerns
Hey @turrizt - definitely appreciate the concern here.
I understand that the pros and cons were carefully considered. Aside from the thorough testing that @Alan_PureStake mentioned, a 24 hour period will allow for several rounds to pass with smooth block production, etc. Smoke tests monitoring Moonriver should alert for any abnormal behavior.
The urgency here is that there is concern that certain thresholds could be hit that could prove much more difficult to recover from. The analogy of the Frog being slowly boiled alive was used and I think quite apt.
After careful consideration, the Moonbeam Council and Tech Committee have elected to move forward with the fast tracking and the community is urged to weigh in by voting:
Thank you for taking the time to address my concerns and provide such a detailed answer, Alan! your explanation has been very helpful and makes a lot of sense, we truly appreciate it!
I completely agree with you, Aaron. Thank you for providing such a detailed explanation, it’s much appreciated. in fact, i decided to ask the question on behalf of the entire community because i believe it’s important that everyone has a clear understanding of the situation. Thank you again for your quick and informative answer!
I’m in full support as well
read the proposal and fully supported
Solving issues related to explosive growth in network utilisation is first world problems 
Things looking bullish for moonbeam, well done
As an update both Moonriver and Moonbeam have both been successfully upgraded to RT 2302 with all Smoke Tests passing.
As we can see from the graph above from @Alan_PureStake, the dynamic fees have helped to curb the behavior and have reduced the rate of increase.
This may have bought some time but the fundamentals of the underlying storage issue remain - it has just been slowed somewhat.
Some sort of solution will be needed to make it unaffordable/undesirable to create many smart contracts under different addresses solely as a form of “proof of participation” (or “proof-of-spam” minting as some are calling it) with no effective sybil resistance in place.
To this end, a group of core developers are working on several proposals to mitigate this issue. Some of the ideas being explored include (but are not limited to):
The solutions discussed so far have pros and cons associated with each of them and will be posted to the community forum for discussion. These proposals will require careful review by as many stakeholders as possible to ensure the best possible outcome. Ultimately, the implementation of one or more of these proposals can only happen if supported by the Moonbeam and Moonriver communities through governance.
Stay tuned for a Forum Post dedicated to this topic.
thanks for the explanation bud, fully agreed this is needed
I get it now that I look over everything I think it's a great idea...