cerc-io/solidity
16
0
Fork 0
mirror of https://github.com/ethereum/solidity synced 2023-10-03 13:03:40 +00:00
Code Issues Actions Packages Projects Releases Wiki Activity

Consolidated term to reentrancy

Browse Source
This commit is contained in:
Nuno Santos 2023-03-28 12:28:31 +01:00 committed by GitHub
parent 5dbfa9409b
commit 7974a3cf7c
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
2 changed files with 6 additions and 6 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
docs/common-patterns.rst
View File

@ -55,7 +55,7 @@ you receive the funds of the person who is now the richest.
function withdraw() public {
uint amount = pendingWithdrawals[msg.sender];
// Remember to zero the pending refund before
// sending to prevent re-entrancy attacks
// sending to prevent reentrancy attacks
pendingWithdrawals[msg.sender] = 0;
payable(msg.sender).transfer(amount);
}

10
docs/security-considerations.rst
View File

@ -47,7 +47,7 @@ local variables and state variables marked ``private``.
Using random numbers in smart contracts is quite tricky if you do not want
block builders to be able to cheat.
Re-Entrancy
Reentrancy
===========
Any interaction from a contract (A) with another contract (B) and any transfer
@ -97,7 +97,7 @@ as it uses ``call`` which forwards all remaining gas by default:
}
}
To avoid re-entrancy, you can use the Checks-Effects-Interactions pattern as
To avoid reentrancy, you can use the Checks-Effects-Interactions pattern as
demonstrated below:
.. code-block:: solidity
@ -119,11 +119,11 @@ demonstrated below:
The Checks-Effects-Interactions pattern ensures that all code paths through a contract complete all required checks
of the supplied parameters before modifying the contract's state (Checks); only then it makes any changes to the state (Effects);
it may make calls to functions in other contracts *after* all planned state changes have been written to
storage (Interactions). This is a common foolproof way to prevent *re-entrancy attacks*, where an externally called
storage (Interactions). This is a common foolproof way to prevent *reentrancy attacks*, where an externally called
malicious contract is able to double-spend an allowance, double-withdraw a balance, among other things, by using logic that calls back into the
original contract before it has finalized its transaction.
Note that re-entrancy is not only an effect of Ether transfer but of any
Note that reentrancy is not only an effect of Ether transfer but of any
function call on another contract. Furthermore, you also have to take
multi-contract situations into account. A called contract could modify the
state of another contract you depend on.
@ -429,7 +429,7 @@ should be the very last step in any function.
Early contracts delayed some effects and waited for external function
calls to return in a non-error state. This is often a serious mistake
because of the re-entrancy problem explained above.
because of the reentrancy problem explained above.
Note that, also, calls to known contracts might in turn cause calls to
unknown contracts, so it is probably better to just always apply this pattern.