Loops between modules

Since Move also will allow one module (smart contract) calling a public function of another module, do the same security measures as in Solidity need to be taken like the Checks-Effects-Interactions Pattern for example?
Because resources can not be duplicated, but the values in a resource - because of the account model - can be drained, right?
Or which measures are taken so that a developer can not introduce such errors and can securily implement any code without having to implement a Checks-Effects-Interactions Pattern?

Hi Bram,
I assume you are referring to the re-entrancy issues of the EVM—please correct me with a specific problem you are concerned about if I am wrong about that.

As we mention in the “Transaction scripts” paragraph in Section 5 of the Move paper, there is no equivalent of re-entrancy issues in Move. This is because:

(1) Move has no dynamic dispatch; all call sites are statically determined, and
(2) Module dependencies in Move are acyclic.

The combination of these two properties means that any call site either invokes a procedure that has already been published on the blockchain or code from the same module. Re-entrancy attacks requires that a procedure p invokes some other procedure evil that calls back into p in the way that the original implementer of p did not anticipate. This is not possible in Move—the implementer of p can statically determine every procedure that p can call.

3 Likes

Yes, that was exactly what I was referring to.
Thanks a lot for the answer and the new insights.

1 Like