> 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?

It's mostly neglect on behalf of the teams. In this case, the code was never audited and was created by a rather immature team that was rushing for production. So recupe for disaster.

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.

>So, as usual, the problem is solvable with a little diligence.

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.

It wasn’t overlooked - someone noticed the issue and reached out to the team just before launch but it was declared ‘FUD’. Ultimately it’s a junior team - this should have been caught. While not perfect, smart contracts are starting to mature - well-tested contracts become templates, access to 100% control flow fuzzing becomes easier, more people are releasing testnet versions with bug bounties… it is going in the right direction but only if you can be bothered to put that effort in. Ive worked as a contract test engineer in crypto for over three years now across several projects & blockchains, and yet to have a project have an issue like this.

True believers think court interpretation is inherently corrupt and a systemic flaw, while these are just implementation bugs and ultimately fixable. Everyone else is either running a con, or a mark. There's really only three categories here and very little to miss I think.

Each time I’ve given crypto a chance, I get about 5 minutes into looking at Ethereum contracts and the EVM and end up walking away because it’s such a mess IMO. It really all feel very junior.

At this point I wouldn't bother with smart contracts and just use it as a medium of exchange or investment.

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.

How do you use ETH on a contract to purchase goods? How does the contract know when it has been completed?

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.

You put $10k in escrow to buy a house. Either both parties agree (human intervention) that the requirements have been met and the escrow is released to the seller, or the funds are returned to the buyer after some deadline.

Always good to have a consultant around to explain the tough words ;)

> How does the contract know when it has been completed?

Escrow, or an oracle (checking, say, FedEx delivery.)

There already is: https://openzeppelin.com/

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.

What do you dislike about the EVM?

This is admittedly secondhand knowledge, but my understanding is that the EVM was written with 128 bit words, and consequently cannot be implemented using any common general purpose computer hardware. All of its operations have to be implemented in software, making it significantly slower than it could be as a result.

Isn't the whole point making the decentralized network itself the computer...?

Market makers need the ability to process transactions quickly. There is indeed a network of computers involved, but each computer is, well, a computer, and needs to make computations in order for transactions to process.

Does a zkEVM by Loopring+Vitalik consulting on it scratch your itch?

If you code it properly you can release a new version and disable the old version, forcing your users to use the new contract. It doesn't mean you can retrieve the money locked by this particular contract though. If the logic doesn't allow it you're out of luck.

To me this almost seems like an argument to insist on legal level protections for development of contractual code. As in, you need to have qualifications like a lawyer, liability coverage like a lawyer (or bank) and have to be approved in some fashion before you can publish a contract that deals with more than a certain amount of capital.

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.