Do you write smart contracts? Want them to be safe and efficient? Read on!
The state of smart contract languages could historically be categorized as lacking constructs that drive programmers to write safe code and being inefficient due to poor optimizations. Oftentimes, programmers write lower level code riddled with footguns in pursuit of gas savings. What if safety and efficiency weren’t at odds?
Here’s how we can eliminate an entire class of bugs without spending an exorbitant amount of gas on safety checks thanks to EIP-1153!
For example, take the following smart contract (Figure 1) which exhibits “read-only reentrancy”. Currently, nothing prevents the following call sequence from succeeding despite there being ambiguity about what value will be returned by DataRace.price during call sequence, X.
Callstack [DataRace.withdraw, msg.sender, X, token.transfer]