Merge pull request #31 from IaroslavMazur/patch-1

Logical mistake in checks_effects_interactions.md

docs/checks_effects_interactions.md

@@ -20,7 +20,7 @@ Participating entities in this pattern are the called function, as well as the c
 
 ## Implementation
 
-To implement the Check Effects Interactions pattern, we have to be aware about which parts of our function are the susceptible ones. Once we identify that the external call with its insecurities regarding the control flow is the potential cause of vulnerability, we can act accordingly. As stated in the Motivation section of this pattern, a re-entrancy attack can lead to a function being called again, before its first invocation has been finished. We should therefore not make any changes to state variables, after interacting with external entities, as we cannot rely on the execution of any code coming after the interaction. This leaves us with the only option to update all state variables prior to the external interaction. This method can be described as ["optimistic accounting"](https://ethereum.stackexchange.com/a/12233), because effects are written down as completed, before they actually took place. For example, the balance of a user will be reduced before the money is actually transferred to him. This is not a problem as will be seen in the [Secure Ether Transfer pattern](./secure_ether_transfer.md), because in case something goes wrong with the money transfer, the whole transaction can be reverted, including the reduction of the balance in the state variable. Combined with the [Guard Check pattern](./guard_check.md), which states that checks should be implemented towards the beginning of a function, we get the natural ordering of: checks first, after that effects to state variables and interactions last.
+To implement the Check Effects Interactions pattern, we have to be aware about which parts of our function are the susceptible ones. Once we identify that the external call with its insecurities regarding the control flow is the potential cause of vulnerability, we can act accordingly. As stated in the Motivation section of this pattern, a re-entrancy attack can lead to a function being called again, before its first invocation has been finished. We should therefore not make any changes to state variables, after interacting with external entities, as we cannot rely on the execution of any code coming after the interaction. This leaves us with the only option to update all state variables prior to the external interaction. This method can be described as ["optimistic accounting"](https://ethereum.stackexchange.com/a/12233), because effects are written down as completed, before they actually took place. For example, the balance of a user will be reduced before the money is actually transferred from him. This is not a problem as will be seen in the [Secure Ether Transfer pattern](./secure_ether_transfer.md), because in case something goes wrong with the money transfer, the whole transaction can be reverted, including the reduction of the balance in the state variable. Combined with the [Guard Check pattern](./guard_check.md), which states that checks should be implemented towards the beginning of a function, we get the natural ordering of: checks first, after that effects to state variables and interactions last.
 
 This method of ordering function components was first described and named in the [Solidity documentation](http://solidity.readthedocs.io/en/v0.4.21/security-considerations.html#use-the-checks-effects-interactions-pattern). The checks in the beginning assure that the calling entity is in the position to call this particular function (e.g. has enough funds). Afterwards all specified effects are applied and the state variables are updated. Only after the internal state is fully up to date, external interactions should be carried out. In case this order is followed, a re-entrancy attack should not be able to surpass the checks in the beginning of the function, as the state variables used to check for entrance permission have already been updated.