From my outside perspective, it sounds like Ethereum makes it hard to avoid subtle bugs when writing contracts. Some of its competitors specifically try to avoid this, e.g. https://docs.cardano.org/en/latest/
My understanding is that the bug was in a particular contract written using the Ethereum contract "language", not Ethereum itself. E.g., one does not stop using Python because there's a bug in Quora
OTOH, Ethereum really encourages these types of bugs due to how it's setup.
These types of bugs are characteristic to things written in Solidity. So no, Ethereum didn't have a bug, it just encourages buggy programs, and this is great example.
Most of the 'holes' mentioned have to do with contract developers writing buggy code rather than bugs with Ethereum / Solidity itself. That being said, there's likely holes that aren't discovered yet, but the title and article is a bit misleading in that it points to flaws with Ethereum itself.
I never got the impression that HN “hates” Ethereum, but I will say that the primary language used for writing smart contracts on the Ethereum blockchain has some disconcerting properties.
It is still not entirely clear to me how much of these things are problems with Solidity (name of said language) only, or if any of those issues are core to the Ethereum Virtual Machine (EVM) itself.
I remain hopeful that other languages targeting the EVM will bring to fruition the full potential of Ethereum in a safer manner.
Also some people dislike the fact that Ethereum is executing every program for every message on every blockchain node. I agree that it would be better if it didn’t have to do so but I don’t know how it could be avoided in a distributed trustless system.
The point is that in Ethereum's case, the extent of the problem is vastly underestimated by almost all of the participants. In most other cases, it is a risk that can be mitigated or accepted, but in Ethereum's case, it undermines the fundamental premise ('trustless' contracts.)
Anyone who works with code will know that bugs happen all the time. Semantic bugs can be hard to anticipate, and are sometimes not obvious even to highly knowledgeable reviewers.
The big fallacy underlying the hard fork is the idea that bugs like this will only happen this one time and so the benefit of stealing the money back and giving it to community early adopters outweighs the costs to the institutional credibility of Ethereum.
In reality, there will be many, many more bugs in smart contracts where the intent of the coder does not completely match the behavior of the smart contract in the real world.
The Ethereum community, and notably its core team who wrote the code for the hard fork while claiming to be neutral in the matter, has sent a strong message that it will meddle in the outcome of contracts in which there was no VM bug.
Human institutions are relatively vulnerable to corruption. There is all sorts of graft, favoritism, etc., throughout most human institutions. Ethereum, because of the concentration of power among early adopters, is still vulnerable to this sort of corruption. We've seen it happen with the hard fork.
Is it a big deal? Well, the invisible hand should have awarded the spoils of the theft to the talented hacker who exploited the contract. Those who lost money in the DAO are people who followed a herd mentality and did not insist that the smart contract they trusted be vetted.
Formal verification will help somewhat, as will the improvement of coding practice. I saw some code written by someone involved in the DAO that was written in a way that made it hard to understand the side-effects of various calls. I'd highlight this if doing code review for a simple e-commerce cart, and it suggests that semantic clarity and readability were ranked low on the list of priorities, favoring a denser style that is much more demanding of the reader's understanding of the subtleties of the language.
What is missing is the simple idea of insurance. Suppose investors in the DAO had been allowed to buy insurance against the DAO malfunctioning... This could have been written as a simple smart contract "future" and could have been offered by anyone. So long as there was demand for both sides of the outcome, a price would have emerged to insure one's investment.
So I think we're on a slippery slope, most notably because of the silly idea that this was the last smart contract bug that will be highly significant or controversial.
Cryptocurrencies bootstrap by appealing to speculators who don't really care about the principle of how it's supposed to work, they just want to buy it early and wait for it to get big (as many did with BTC but many more wished they had). This is fine, but we saw the same sort of greed infect a lot more people, and a hard fork (bailout) occur soon after. You can call it adaptability, you can call it a bailout, it doesn't matter. The bottom line is that at present Ethereum is still vulnerable to it and will be for a while. Let's hope Ethereum grows to the point where a small cabal of people who made a bad investment (or hold a particular political view) can't undermine the system.
I believe it's not core Ethereum that has issues, it's buggy smart contracts. They don't make it particularly difficult to write insecure contracts, though.
This pretty directly contradicts a lot of the hype around Ethereum. Yes, bad contract code is bad, but a lot of money is about to evaporate. If it isn't easy to write secure contracts then there is a serious deployment problem.
This might sound mean, but I laugh every time I see Ethereum bugs in the headlines. The developers intentionally made their platform analytically intractable, despite knowing the dangers this presents given our long history of vulnerable software.
They then compounded this poor choice with an Ethereum programming language with poor and insecure semantics.
I applaud the ambition behind Ethereum, but not it's technical choices.
the problem isn't actually Ethereum, but the tools they provide for writing smart contracts. the exploits are in contracts, not EVM.
that doesn't actually make it better, but it does highlight the problem of using code as an absolute arbiter b/c it can be hard to tell if it describes your intent accurately or not.
Before 2018, Ethereum has a similar downtime to Solana
Ethereum is continuously developed to remove bugs.
For example: Until 2017, it was possible to sent a specifically signed transaction (without the correct private key) that resulted in the msg.sender having null sender address. This was fixed in EIP-86
reply