Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Language-based fix for "Callstack attack" bug #656
See this work by Andrew Miller and Zikai Wen (don't know their GitHub usernames):
The work-around they recommend is highly unintuitive and seems poorly documented, with the bug affecting a "majority of smart contracts":
Apparently this bug has caused the loss of thousands of $ worth of ETH already, and therefore seems like something that should receive special attention from the language, perhaps deprecating "send" and creating a new language construct for doing it.
This issue is a good idea. (The post authors are myself and @alexwzk)
Note that the underlying problem is also carried over from Serpent, and it's in part a consequence of peculiarities of the EVM itself. https://github.com/LeastAuthority/ethereum-analyses/blob/master/GasEcon.md#hazards
The Solidity compiler is a great place to put warnings. One option might be to make it an error to use
It would be a also be a good idea to try to address the "reentrancy" hazard in the same way, perhaps by providing Solidity support for macros, but I guess that should be a different issue.
We are thinking about deprecating ether and replacing it by a token contract (and then issuing a warning for the use of
We could create a token contract (that complies with the standard token API) where you can send ether and receive exactly 1 token per wei. In the same way you can always convert those tokens back into wei.
Transferring tokens and paying with those tokens will be done using the standard token API.
Recommending programmers to use that token contract instead of ether would also automatically open up your contracts to all other tokens that might exist, because they share the same API.
This is also in line with making Ether less special among all currencies/tokens in Ethereum.
In a world of perfectly rational people this position is correct and reasonable.
But developers on the ethereum blockchain are not perfectly rational people.
You don't only need to empower competent developers you need discourage malicious and incompetent developers
Even in your above quote you're implying that merely "knowing" the contact will provide any smart contract developer with the knowledge of if the contract is malicious or not!
If it's trivial to detect malicious contracts, than it should be addressed in the compiler and run-time. if it's not trivial to detect malicious contracts, maybe the platform should be modified to make such detections trivial. If you believe such detection is impossible or intractable then you are conceding that your platform will never meet reasonable security assumptions and you should publicly advocate your beliefs.
Wouldn't using tokens just introduce a layer of indirection, where re-entrancy attacks still apply just with tokens rather than Ether?
Would the language allowing send/call only at the end a public function and the compiler using static analysis to ensure that any path through the code from that function doesn't include any other sends/calls "good enough"?
Or is that naive. :-/
Wondering if either of these questions from #662 have relevance to this issue as well?
EDIT: copy/pasting addendum from #662:
I.e. in a message-passing model, these types of reentrancy bugs should be impossible, I believe.
There is just a queue of messages. That's it. No "function calls".
This is what makes Erlang so stable and is also the model that is used by "latest hotness" elegant & safe languages like Elm.
EDIT2: Also, see Clojure's Agents, a variant of the Actor approach.