Since software will always have bugs, how do developers of smart contracts intend to fix this kind of problem? Does anyone actually have a solution to this?
Only bad news sells. A $35 million bug makes it to the front page, but how often do you hear about Uniswap processing $1+ billion in trading every day without a single hack in 5 years.
In general, there’s actually been a sustained improving trend of fewer hacks, higher likelihood of recovery, and lower losses as a percent of assets. The headline numbers may be higher, but that’s largely a denominator effect of the meteoric growth in on-chain assets. It’d be like judging New York City based on how many murders are in the paper instead of the murder rate.
This leads to bugs or exploits often ending up in these "contracts". The concept is inherently flawed, as they can't be updated and can't be reevaluated or reinterpreted by e.g. a court. The money's just lost.
This is the way it seems to me too, but I just can't understand how a flaw this obvious could be overlooked by so many people? Surely we are both missing something?
In truth you can write code that is upgradable or ammendable, but always within limits of Ethereum transactions being immutable. However, when a project wants to emphasize that immutability, because that's perceived as the need by the users and the devs, then you end up in this situation.
So, as usual, the problem is solvable with a little diligence. The challenge is for crypto culture to get over itself and mature and actually perform that diligence.
I will say that there are very mature, very well developed projects that you don't hear about getting hacked, because they take advantage of the wealth of experience that's been built on this subject.
If you're going to potentially lose tens or hundreds of millions, you need a lot more than a little diligence. Formally proved code (something along the lines of Ada with Spark Pro) is the bare minimum for something with some much money on the line, and even then I'd still prefer a traditional contract and leave things to the courts.
However, if Ethereum sticks around there will be standardized, off the shelf contracts for people to use that have wide-spread testing/adoption. Once we reach that level of maturity then it could make sense to use it for things like escrow on a contract/purchase.
I can imagine using ETH for escrow; but there has to be a human in the loop for escrow, to direct escrow funds to be released. I guess one could contrive a situation where a "contract" could autonomously determine when it had been completed. But that's not the general case.
Escrow, or an oracle (checking, say, FedEx delivery.)
Most people use them for their projects, but you don't hear about them because they don't make it to hacker news as only crypto pessimism is upvoted here.
Theres no difference between a badly codes contract and a badly written one that doesn't do what one signer intended. Short of you can try to convince a judge to adjust it or handle it differently.
In this case. There is no judgment system to allow for reversal of badly coded or misunderstood contracts. Which means that the standard for the development should be far higher with considerably more insurance and coverage for risk.
They don't. I doubt most are even thinking about it, and of those that are, most probably think it can't happen to them.
Crypto tries to make financial programming more like web development, and less like writing code for a bank, but there's a reason writing code for a bank is such a pain in the ass: it has to work more or less perfectly, every time, at least on the backend.
If you trust your financial framework to someone who took a UDemy course last weekend, you get what you deserve.
When a smart contact developer makes a mistake, your money is just gone, forever, with no recourse.
This is wrong. It's pretty standard for contracts to be able to be upgraded. Usually you want to put a delay before updates are applied. This time delay allows users to see what is happening with the upgrade and gives them a chance to cash out if it's bad.
There might also be a way to do an emergency upgrade, but typically this account is much more locked down compared to just being able to make a normal update.
Because it’s code which means errors are a fact of life, and the goal of crypto pushers was to spread the scam so instead of looking at formal methods in order to make “smart” contract ironclad, they started from ECMAScript so that any idiot could go from a frontend widget to deploying a smart contract with minimal introspection or reflexion.
Maybe one day there will be a sort of unhackable template that everything derives from, or an automatic software-prover.
Companies get hacked every single day too, probably many that you use, it's just more opaque when that happens.
So my guess as to why it keeps happening is a sort of Dunning Kruger effect combine with a selection filter such that the people most eager to get involved are the ones least likely to be able to spot the problems.