Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.
Sign upVIP: Reentrant Lock Decorator #1204
Closed
Labels
Comments
This comment has been minimized.
This comment has been minimized.
Should the first line of the
|
This comment has been minimized.
This comment has been minimized.
Added the edit! |
This comment has been minimized.
This comment has been minimized.
I don't think we should "enforce" this as a default, rather this is a good tool for developers to use in situtations where it is called for We should instead raise warnings of when a function should have this decorator, to reinforce the pattern that not every function will need it |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
Marked as accepted, |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Simple Summary
Add a decorator called
@nonreentrant
to be used on all functions that handle funds and at the discretion of the developer.Abstract
Using a lock around a function call one can prevent a function doing send / external call with value to do a re-entrant call.
Motivation
Re-entrancy is super difficult to detect as a programmer, Vyper should make it simple not to introduce or hard to get wrong.
As an extra security measure it is encouraged to force the usage of
@nonreentrant
on functions that are sending funds, either with thevalue=
parameter or thesend()
function. This is just an extra layer of protection, however attacks are still possible if a function uses state-setting and fund moving in separate transactions.Specification
Using a unique identifier per function (derivitive of method_id), we can set a lock per function. See https://github.com/protofire/zeppelin-solidity/blob/master/contracts/ReentrancyGuard.sol.
In pseudo vyper code this would be the equivelant of something like:
Backwards Compatibility
This will effect backwards compatibility if this becomes a forced decorator, if only an optional decorator it will not effect backwards compatibility.
Dependencies
Optional Implementation of
@nonreentrant
: None (5200 gas per application)Forced implementation of
@nonreentrant
: Net-Gas Metering (400 gas per application, well worth it!)Copyright
Copyright and related rights waived via CC0