search

ethereum / langlab

MIT License
10 stars 5 forks source link

How to deal with (allowing/preventing) reentrancy? #3

Open markusvoelter opened 7 years ago

markusvoelter commented 7 years ago

@chriseth What I wonder is how you define "reentrant". I also wonder whether disallowing reentrancy is really necessary, I always thought that limits called contracts in an unpredictable way. Should we perhaps syntactically enforce the checks-effects-interactions-pattern, i.e. only allow external calls after the update phase (but also allow STATICCALL calls / calls to "query" functions before)?

@pirapira reentrancy prevention: somehow the language needs to be aware that calling another contract is a source of reentrancy. It's a good consideration that internal functions not calling api functions, but not enough.

kbirken commented 7 years ago

The major reason why this should be controlled more closely is because it currently allows security breaches (cf. https://github.com/ConsenSys/smart-contract-best-practices#reentrancy). The example usecase for "bad" reentrancy would be: api function f of contract A calls some api function of contract B, which again calls f.

markusvoelter commented 7 years ago

There is a whole group of issues relating to the collaboration between contracts: