Challenge: EmpowerChain Claim C2: Filter relaying about gon-evidence HOT 3 CLOSED

FYI. I've updated the issue with more details (in case someone has already read it, it might contain more interesting concepts now)

from gon-evidence.

Instead filtering by events, it should be filtered by packet data, since in the GoN attack that occurred, packets were sent when IBC Recv, IBC Ack transactions were executed, where the sender is the relayer. Filtering the classId/contract that caused the spam, avoids validating multiple user addresses.

The difference with the spam that a normal user can send is that the attacker has to pay the fees for Transfer Tx, in the contract attack the fees were paid by the relayers themselves.

Although the solution for the GoN spam is to limit the gas consumed by a contract, so that the contract can no longer write packets. This is the way cw-ICS20 works, which has not suffered from this spam problem.

from gon-evidence.

@giansalex that might be possible to do as well, but it might not be a good idea. Downloading and parsing all packet data would be much harder, more resource heavy, and less flexible of a solution.

The GoN spam needs to be sorted on the contract level too, this is true, but the goal here wasn't just to solve that particular problem. The challenge was broad because this is a potential problem not just with that attack. You can still swamp IBC channels today without a hack - sure it will cost you a little more, but the cost of a manual attack like this (over a short period of time at least) is not high.

My goal with this challenge was to find a flexible solution that could be applied quickly during operation to quickly filter out packets (and events are what are most easily available to the relayer) so that when a new situation arises, it can be dealt with sooner.

from gon-evidence.