Can someone please provide an answer of what will happen on this scenario? And it’s true that canisters burn cycles based on traffic of the website?
Canister developers can reject or rate-limit requests based on logic, to avoid this kind of thing.
Canister to Canister an attacker would need to pay cycles to do the attack. Given someone with enough money they can burn your tokens. @tacodaoicp has a nice spam system that at least slows an attacker down, but given enough money and time someone can certainly put a strain on you. This is exacerbated a bit by some holes in the candid syntax that make it easier depending on what variable inputs you have for your canister’s functions.
From outside the IC you can do some rate limiting, but it is not super easy to set up and because users can generate infinite principals you’re somewhat dependent on the boundary nodes to do some IP based magic.
There are some solutions and some frameworks that can be put in place for these things. It will be a good problem to have when we have something valuable and interesting enough for someone to try to attack it this way.
1 Like
We actually have an example of this recently happening.
Adam set up a bot to transfer nicp between wallets to try and drain the canister cycles.
2 Likes