Consider native re-entrancy guard

[adlerjohn]

Re-entrancy has historically been a significant issue for smart contracts on Ethereum. We should consider a native re-entrancy guard that panics when a contract is called but already has a call frame on the stack. There are some issues with supporting this however: since we define call frames recursively, without an addition table of "which contract is currently on the stack," proving that a contract is on the stack would require going through every single call frame.

Two alternatives:

1. Add additional metadata to each contract output, a one-bit flag of whether it is on the stack or not. Then, every time a contract is called, it can check this flag. Problems:
   • This is at the granularity of contracts, not functions. This coarse granularity may not be good enough, but introduce extra complexity and overhead to the VM.
2. Make the high-level language compiler check for the check-effects-interaction pattern and enforce it with an (optional, but on-by-default) compiler flag. This solves the issue entirely with no additional complexity or cost in the VM or the generated bytecode.

My recommendation is simply to do (2).

[Arachnid]

Oh, please don't. Reentrancy itself is not a bug. #2 sounds better if you can do it - but in many cases you can be reentrancy-safe without it, and in others it's not possible to structure your code in that way.

If you make your shared memory model a little more flexible, people can implement low-cost mutexes in memory, much more efficiently than the EVM's storage.

[adlerjohn]

Closing in favor of (2) at FuelLabs/sway#10.