Don't these contracts existing in a market? If one contract is flawed won't customers flock to another competing one? This would create an incentive for quality control.
Or is the proposed problem that these flaws are unavoidable or too costly to prevent? I could see the high-investment cost being a deterrent for developers to adopt the platform. In general the contract code should be as simple as possible and memory safe.
Either way, the sample reference in the article is not very useful. This is a bad time to be looking for quality as this is extremely early and very much in the experimental stage of the idea. It will, of course, deserve scrutiny when it gets more mature though.
From my review of some of these contracts, even fairly obvious flaws are not being exploited (yet).
So, flaws will become known, and presumably there will be ratings and trust ratings and so on eventually. In the interim, though, some of the flawed contracts moved well over $100k in their first week of existence. That seems worth paying attention to.
I would propose flaws like these are unavoidable, unless you can pay what NASA paid. And remediation techniques should be developed urgently, not at some later date.
How would the average Ethereum speculator know that the contract is flawed? Given the limited success of other, much easier-to-use blockchain technologies I'm skeptical that Ethereum can reach critical mass if every participant must learn the Solidity language and conduct a complete code review of any contracts they call. It seems to me that the Ethereum marketplace has to be married to some kind of source of trust, even one as simple as an upvote/downvote system.
If one contract is flawed won't customers flock to another competing one?
Market is small so competition won't be strong; customers aren't professional security reviewers, so have no idea about flaws. What's most likely to happen is people putting money in and then losing it when an attacker discovers the flaw. That will put people off the whole smart contracts concept.
Or is the proposed problem that these flaws are unavoidable or too costly to prevent? I could see the high-investment cost being a deterrent for developers to adopt the platform. In general the contract code should be as simple as possible and memory safe.
Either way, the sample reference in the article is not very useful. This is a bad time to be looking for quality as this is extremely early and very much in the experimental stage of the idea. It will, of course, deserve scrutiny when it gets more mature though.