Merge pull request #28 from onflow/bastian/fix-reentrancy-notes

Remove incorrect statements about reentrancy
onflow · Dec 1, 2023 · be51b91 · be51b91 · vercel · Dec 1, 2023
2 parents 6a2e179 + 4555454
commit be51b91
Show file tree

Hide file tree

Showing 4 changed files with 0 additions and 14 deletions.
diff --git a/docs/tutorial/04-capabilities.md b/docs/tutorial/04-capabilities.md
@@ -285,11 +285,6 @@ The reference could be `nil` if the targeted storage slot is empty, is already b
 or if the requested type exceeds what is allowed by the capability.
 We panic with a descriptive error message so the caller can know better what went wrong.
 
-We separate this process into capabilities and references to protect against reentrancy attacks.
-A reentrancy attack is where a malicious actor could call into an object multiple times.
-These attacks have plagued other smart contract languages.
-Only one reference to an object can exist at a time, so this type of vulnerability isn't possible for objects in storage when you use Cadence.
-
 Additionally, the owner of an object can effectively revoke capabilities they have created by moving the underlying object or destroying the link with the `unlink` method.
 If the referenced object is moved or the link is destroyed, capabilities that have been created from that link are invalidated.
 

diff --git a/docs/tutorial/06-fungible-tokens.md b/docs/tutorial/06-fungible-tokens.md
@@ -745,8 +745,6 @@ transaction {
 In order to use a capability, we have to first create a link to that object in storage.
 A reference can then be created from a capability, and references cannot be stored.
 They need to be lost at the end of a transaction execution.
-This restriction is to prevent reentrancy attacks which are attacks where a malicious user calls into the same function over and over again
-before the original execution has finished. Only allowing one reference at a time for an object prevents these attacks for objects in storage.
 
 To create a capability, we use the `link` function.
 

diff --git a/versioned_docs/version-1.0/tutorial/04-capabilities.md b/versioned_docs/version-1.0/tutorial/04-capabilities.md
@@ -285,11 +285,6 @@ The reference could be `nil` if the targeted storage slot is empty, is already b
 or if the requested type exceeds what is allowed by the capability.
 We panic with a descriptive error message so the caller can know better what went wrong.
 
-We separate this process into capabilities and references to protect against reentrancy attacks.
-A reentrancy attack is where a malicious actor could call into an object multiple times.
-These attacks have plagued other smart contract languages.
-Only one reference to an object can exist at a time, so this type of vulnerability isn't possible for objects in storage when you use Cadence.
-
 Additionally, the owner of an object can effectively revoke capabilities they have created by moving the underlying object or destroying the link with the `unlink` method.
 If the referenced object is moved or the link is destroyed, capabilities that have been created from that link are invalidated.
 

diff --git a/versioned_docs/version-1.0/tutorial/06-fungible-tokens.md b/versioned_docs/version-1.0/tutorial/06-fungible-tokens.md
@@ -745,8 +745,6 @@ transaction {
 In order to use a capability, we have to first create a link to that object in storage.
 A reference can then be created from a capability, and references cannot be stored.
 They need to be lost at the end of a transaction execution.
-This restriction is to prevent reentrancy attacks which are attacks where a malicious user calls into the same function over and over again
-before the original execution has finished. Only allowing one reference at a time for an object prevents these attacks for objects in storage.
 
 To create a capability, we use the `link` function.