Prevent common & tricky bugs at compile time

[WilfredTA]

What is wrong?

There are many classes of bugs and unexpected behaviors that can occur in smart contracts. There are many resources cataloguing and classifying these. There is also available research on how to prevent them with proper design patterns in languages such as Solidity as well as on experimental languages that prevent them with different type systems. It is currently only partially defined what Fe's type system is. It is also unclear which classes of errors or unexpected (but non-erroneous though non-desirable) behaviors that are prevented by Fe.

How can it be fixed

We should skim available research and compile a history of notable so-called "smart contract hacks". Then, we should identify how these problems can be reduced to statically detectable patterns and/or type errors, which we can then incorporate into Fe's compile-time analysis and type checking.

In many ways, smart contract execution is similar to a single threaded concurrent program. Therefore, some of the more sophisticated issues that appear in smart contract systems are potentially resolved by principles similar to those employed by compiled languages that are meant to provide strong protection against concurrency bugs.

[cburgdorf]

Just to add a concrete example based on a recent vulnerability in SushiSwap that is explained in detail here

The specific issue of using msg.value in a loop that performs a mutation could be abstracted as some combination of lifetimes + mutability. A naive and potentially overly restrictive concept would be "values that last longer than current scope can only be read once by functions with side effects.

[g-r-a-n-t]

Sigp's solidity security blog is a pretty good resource.