VIP: disable re-entrancy by default

[charles-cooper]

Simple Summary

per title

Motivation

once EIP-1153 is enabled, the cost of disabling re-entrancy into a contract before the selector table is even traversed comes down to two TSTOREs and one TLOAD, so approximately 300 gas, which is a small overhead compared to even the cost of a warm CALL, 200 gas. re-entrancy attacks are one of the biggest sources of vulnerabilities in smart contracts (todo: gather some hard stats on this), and it makes sense from a safety perspective to disable them by default. in the future, i also expect a future EIP will bring the cost of TLOAD/TSTORE down in the general case.

Specification

there are multiple possibilities here:

1. introduce a LOCK keyword, which creates critical section/non-reentrant blocks. ex.

   LOCK:
       some_contract.foo() # re-entrancy back into this contract unavailable here

2. disallow re-entrancy entirely (allow re-entrancy at call site by a new syntax), ex.

   some_contract.foo() # re-entrancy back into this contract unavailable here
   some_contract.foo(..., reeentrant_functions=(func1, func2)) # func1 and func2 can be re-entered into
   some_contract.foo(..., reentrant_functions=*) # all functions can be re-entered into

EDIT: it seems the preferred implementation in terms of language design will be to remove the current @nonreentrant decorator and replace with an @reentrant decorator (with inverted semantics)

Backwards Compatibility

this fundamentally changes the behavior of existing vyper contracts. to discuss.

Dependencies

will be cleaner to implement syntax-wise with the addition of #2856.

References

Copyright

Copyright and related rights waived via CC0

[fubuloubu]

1. Is too magical, not personally for this
2. Looks pretty good! Seems like it would need function pointer types

Also let's add another option
3. Invert @nonreentrant decorator and have it optionally white-list certain functions

@public
@reentrant # can be called again no matter what call out is made
def all_calls_allowed()

@public # no calls to this allowed after call out
def call_A() 

@public
@reentrant(call_A,...) # can only call this if call out from inside `call_A`
def only_A_reentrancy_allowed()

But in general, 2 seems most flexible since it's at the call site

[jtriley2p]

Agree with @fubuloubu here, the @reentrant decorator with optional functions that may be reentered seems sufficient. In either case, I am on board with non-reentrant by default.

[pcaversaccio]

Fully support disabling reentrancy by default. @charles-cooper if you need hard stats, you can simply link to my reentrancy attacks list: https://github.com/pcaversaccio/reentrancy-attacks. Also, for the sake of completeness, I cross-reference my similar initiative in Solidity here: argotorg/solidity#12996. I think the reentrant decorator with the customisability of who can reenter feels the most ergonomic to me.

[charles-cooper]

inverting the nonreentrant decorator has the benefit of not incurring a performance hit for every function, but it doesn't carry the same level of safety. two thoughts,

1. it could be potentially an "intermediate" stage where we can see how users respond to the change without committing to the full change of only enabling re-entrancy at call site, and
2. these two options are not necessarily mutually exclusive, we could have both reentrancy at call site and also inverted reentrant decorator.

[pcaversaccio]

One comment regarding view functions. You can't disable reentrancy by default for view functions since it would require a state changing operation as part of the tx. Thus, question is whether the decorator reentrant should be allowed or whether there is a better solution to this.

[charles-cooper]

One comment regarding view functions. You can't disable reentrancy by default for view functions since it would require a state changing operation as part of the tx. Thus, question is whether the decorator reentrant should be allowed or whether there is a better solution to this.

the nonreentrant modifier can be used on view functions, see #2921

[pcaversaccio]

the nonreentrant modifier can be used on view functions, see #2921

So you want to keep this decorator as well?

[charles-cooper]

So you want to keep this decorator as well?

that's not what i meant, i'm just saying in the context of view functions, there are still reasonable semantics for nonreentrancy, they are just slightly modified -- the function cannot be "re-entered" into, i.e. it checks the flag even if it does not set it.

[charles-cooper]

2. Looks pretty good! Seems like it would need function pointer types

Btw, no function pointers needed! It would just be the name of the function, it's not really like it's callable or you could pass it to other functions like an object.

[scherrey]

Disabling re-entrancy by default fits with the 'default safe' policies of Vyper. Definitely lets do this. How to deal with the change in backwards compatibility is a bigger question. Maybe a contract level declaration REENTRANT_DEFAULT=True that you'd add to old contracts to get the original semantics? (I suspect a better symbol can be discovered but that's the idea.)

Otherwise - I like @reentrant decorator as being the most pythonic syntax as it addresses meta or non-functional aspects of the function rather than being a runtime expression.

await as a keyword doesn't fit right with me per my comments in #2856.

[pcaversaccio]

For the sake of documentation, linking a very interesting write-up by @0xalpharush on the discussed matter: https://gist.github.com/0xalpharush/15d903ec43334b081caece21a0bd7a20. Also, @jtriley-eth provided interesting thoughts (in Solidity tho) for reflection.

[ControlCplusControlV]

I support this a lot, but I have a couple ideas/questions, I am not sure how useful this one would be but having @reentrant(5) to allow a specific number of re-entrant calls at compile time could allow adjustable safety, although under the surface it might require a different implementation compared to unlimited re-entrancy

[pcaversaccio]

I support this a lot, but I have a couple ideas/questions, I am not sure how useful this one would be but having @reentrant(5) to allow a specific number of re-entrant calls at compile time could allow adjustable safety, although under the surface it might require a different implementation compared to unlimited re-entrancy

Do you have a specific use case in mind where this would be useful?