In Dom’s post to X related to the news that Avax’s Stars Arena lost funds in a reentrancy attack, he cites deploying in ICP as a solution to the reentrancy problem.
Is there a solution to let ICP solve this reentrancy attack? I am concerned that this problem may be more severe due to asynchronous processing. Also, if EVM on ICP comes to fruition, we should have the same problem. there are validation tools such as Motoko-san, but I don’t think this is the fundamental solution. Is there a better solution?
4 Likes
Why are motoko’s eyes x’d out in your dp? Not the first time I’ve seen this done.
1 Like
1 Like
If an update method on an IC canister does not await any other sub-routines, it is atomic, by virtue of running on the IC.
So, the IC provides a minimal kind of atomicity based on the semantics of actors (what the IC calls “canisters”, but what is more widely known as “the actor model”).
This serves as a useful building block, but it’s not a silver bullet: If an update method itself awaits anything asynchronous, then it can be interleaved with other update methods that change the canister state. At that point, the canister needs to coordinate concurrent transactions, just like any other asynchronous service would, and could make use of different concurrently control mechanisms for this.
But still, for very simple update calls, at least the IC builds in a simple (atomic) semantics.
3 Likes
Thank you!
I understand that IC has other forms of reentrancy issues that EVM does not, and the nuances of Dom’s tweet seem to indicate that they are easier to deal with and overcome than EVM in mitigating reentrancy issues due to language differences, etc., but I am not sure if this will be the case in the future. I wonder if IC will have similar reentrancy problems in the future.