3 ms·
I'm still pretty sure that the thing will be hacked before long, or will have critical bugs that will necessitate complex negotiations to fix. It's not just th
by joosters 10y ago
I'm still pretty sure that the thing will be hacked before long, or will have critical bugs that will necessitate complex negotiations to fix.
It's not just the size of the code that is the problem, although that alone practically guarantees that there will be bugs. Ethereum has a couple of unique properties that can cause all sorts of chaos in ways that 'normal' language developers never need worry about.
First of all, code requires 'gas' to run. If there isn't enough gas, then the execution stops. But critically, some but not all of the code's actions are rolled back. Transfers from one party to another still take place. You can imagine a situation where an attacker runs a contract with just enough gas to make the code transfer some money but halt before it records the payout, allowing the withdrawal to be repeated.
Secondly, there's a stack limit for code, again triggering an exception and a partial rollback. Developers are used to having to reason about stack overflows in normal programming situations, e.g. a recursive algorithm. But Ethereum's stack has more problems. It allows attackers to control the available stack space before your code gets run. e.g. an evil-doer could use up almost all of the stack, then call your contract. If the stack runs out at a select inopportune moment, there is potential for abuse.
- chejazi 10y ago> But critically, some but not all of the code's actions are rolled back. This is not true - the actions within the contract are rolled back. You do, however, lose the ether committed to paying the gas cost (cost of execution).
- joosters 10y agohttps://github.com/ethereum/wiki/wiki/Subtleties https://github.com/ethereum/wiki/wiki/Subtleties says: If a transaction triggers an exception, then: * The value transfer from sender to recipient still takes place * The fee transfer from sender to miner still takes place * The entire STARTGAS is added to gas_used * All other execution is reverted Perhaps I am reading that wrong, the 'value transfer' is unclear now that you mention the gas cost. I read it as talking about actual transfers. Can anyone confirm?
- chejazi 10y agoI don't have a document on hand to support my claim, but it's alluded to in the header of the document you linked: THIS DOCUMENT HAS BEEN LAST UPDATED IN MARCH 2015 AND SOME SUBTLETIES HAVE CHANGED SINCE, ESPECIALLY CONCERNING REVERTING ETHER TRANSFERS IN CASE OF OUT-OF-GAS. Based on my understanding, your bullet points are valid excluding the first one.
- brador 10y agoMore likely is sometime the system will be abused to enrich an individual or group who has authority over a part of it. Maybe the developer, maybe a software distributer, maybe someone who writes up it's contracts. Somewhere down the line someone with access will crush it to enrich themselves.
- fapjacks 10y agoYeah, totally. I've been cooking up ways to do this specifically to the DAO, and I'm a pretty nice guy. There's no way this thing won't have brilliant minds and tons of resources working to break it.
- brianpgordon 10y agoDo you have any more information about the stack overflow attack? It's quite concerning to me and searching google for "ethereum stack overflow" is as useless as you might expect.
- joosters 10y agoSorry, I can't find the good example which I read recently, which detailed the problem well. The best source I have right now is: https://github.com/ethereum/wiki/wiki/Subtleties https://github.com/ethereum/wiki/wiki/Subtleties Which details many of the corner cases of the virtual machine, including the stack limits - but it's just a single line mention.