Consider replacing token whitelist/blacklist feature with block percentage restrictions for fee payments

[kmlbgn]

Status quo

At the moment, our network employs a whitelist and blacklist mechanism to manage foreign tokens transfers to prevent threats to our network's spam protection mechanism. This mechanism includes the ability to blacklist or whitelist all tokens for transfers other than KEX, particularly useful when unforeseen issues occur, such as bridge failures. However this method is more of a quick fix than a long-term solution to the problem.

Proposed Change

A more effective solution could involve defining a minimum percentage of a block that must be constituted by transactions with KEX fee payments. This approach would ensure that even if a token gets exploited, KEX transfers cannot be blocked and spam protection holds.

This new system would offer a significant improvement over the current whitelist/blacklist mechanism, as it doesn't rely on governance and therefore is much more efficient in protecting the network. The issues with the bridge have been resolved with the recent introduction of L2 spec and fisherman, so now could be an opportune time to revisit our approach to fee management.

[asmodat]

Yes I agree, it should have been mentioned in one of the specs, one thing it must also include is a guaranteed block space not only for tokens but also for XAM message of L2 applications. I would structure block space as follows:

• 50% - XAM
• 30% - transactions paid with KEX
• 20% - transactions paid with tokens other then KEX

Then this 20% would never be a threat and a simple blacklist/whitelist is sufficient. However, the solution with each token having some configurable MAX (and NOT a MIN) % within the 20% space of the block is also acceptable.

If the block space is unoccupied by foreign tx the 30% of the blockspace for KEX can be expanded to 50%.

If the blockspace is unoccupied by KEX tx and by foreign tx I would allow to example the 50% of the XAM occupied space up to 100%

And so on, making the blockspace more flexible

• That being said I would mark optimizing backspace as low priority

[kiragpg]

This would be hard to implement on Cosmos level since cosmos manages only txs and not block level, it's managed on tendermint side.

[asmodat]

Ok so here is a go-around for this @jgo121 so that we don't have to touch tendemrint, because I do agree forking TM makes no sense at least for now it would be too much work.

The solution is dynamic fees targetting a specific % of block composition, very similar to how many "smart" cities tax parking spaces to target 80% of occupancy (prices for parking raise if occupancy is above 80% and fall it ifs below). Imagine block space being a car park and specific car types being different types of tx paid for in different tokens. If you want your car park or "blockspace" to be occupied in X% by lets say electric cars and in Y% by gasoline cars what you do is charge more for parking (increase min fee) if the number of cars (or nr of tx in the previous block) was more than X% and vice versa you charge less if the number is less then X%.

So in the scenario of spam with some hacked token and infinite supply like LUNA filling 100% of the backspace over a few blocks the fees would go to infinity and exhaust the attacker coins. : ) Lets say you can double min fee prices in specific tokens every time you are 2x more tx then wanted and half the prices going towards the hard min if you dont. This will guarantee that even in the worst case scenario governance will eventually be bale to solve the problem by making proposal and having guarantee of its inclusion in the block.

[kiragpg]

If there's a frontend to use USDC as gas fees, it might be used a lot, not sure if min gas fee should be increased for USDC as well.