From 890e3b1986f05d5d7e4d949ada6ed829dbfe343b Mon Sep 17 00:00:00 2001 From: Tim McMackin Date: Wed, 31 Jan 2024 13:28:44 -0500 Subject: [PATCH] Clarify this scenario --- docs/tutorials/security/part-2.md | 14 +++++++++----- 1 file changed, 9 insertions(+), 5 deletions(-) diff --git a/docs/tutorials/security/part-2.md b/docs/tutorials/security/part-2.md index be841d76b..ff761450a 100644 --- a/docs/tutorials/security/part-2.md +++ b/docs/tutorials/security/part-2.md @@ -89,11 +89,15 @@ sequenceDiagram Note right of LedgerContract: ... Once finish ... UpdateBalance ``` -Why this scenario is possible on Solidity? -On Solidity, the operation will call directly the smart contract, stopping the execution, calling a synchronous execution and resuming the flow. If someone calls several times and very quickly the withdraw operation, as the state is not updated yet, the call will succeed and drain more than the developer expected. - -Why this scenario is not possible on Tezos? -On Tezos, the first transaction will update the state and will execute a list of operations at the end of execution. Next executions will encounter an updated state +Why is this scenario possible on Solidity? +In Solidity, when a smart contract calls another smart contract, that operation runs immediately and synchronously. +The original smart contract pauses, the other smart contract runs, and then the original smart contract resumes. +If someone calls the original smart contract multiple times very quickly, they can generate multiple operations before the original smart contract has updated its state. +In the example in the previous diagram, a user may be able to run many withdraw operations and drain more than the developer expected. + +Why is this scenario not possible on Tezos? +On Tezos, generated operations don't run until the original smart contract is finished and has updated its state. +Future operations encounter the contract's updated state. Let's implement a more complex scenario where the OfferContract and LedgerContract are separated. The OfferContract will naively send the money back to MaliciousContract because it relies on the **not yet modified** state of the LedgerContract. There are two operations and the modification of the state will come in second position.