hey Marin, thanks for bringing up this issue on the forum, it’s much appreciated
It seems like MBIP5 needs adjustments because it actually doesn’t solve the issue we’ve had for over a year now
as for your proposed ways:
-
I don’t think that banning XEN is actually a good thing. first of all, these are still txs that burn fees and interact with the chain. If something big comes to Moonbeam and starts spamming organically, how will we deal with it? I believe we just need to come up with an actually good long-term solution which should help fix the issue so such a thing won’t happen again. banning something contradicts the principles of decentralization and it may also set a precedent that could deter future devs
-
XEN could redeploy their contracts, making this approach only a temp fix
I think we can come up with something like dynamic throttling for contracts that spam the network. when certain thresholds are exceeded, the protocol automatically limits the execution rate of these contracts
also, I see that when XEN spam attacks arise, wallets can’t automatically adjust the gas based on the demand. It would be a good thing if wallets could automatically determine what gas prices need to be set so that they will be higher than XEN txs, ensuring the txs won’t get stuck in the mempool
It seems that Moonbeam contributors are working on short, medium, and long-term solutions rn, so I hope to hear what ideas they have
hopefully, async backing and increasing the gas limit to 60M, as discussed in Increase block gas limit by ahmadkaouk · Pull Request #2735 · moonbeam-foundation/moonbeam · GitHub, will also help in solving the issue