Hacker News Reader

Comment by Glench | Hacker News Reader

Man, it feels like this has been happening a lot. I guess this happens when you have what is essentially JavaScript code on the EVM handling vast sums of money.

View on HN

As many people on this forum know first hand, it's very, very hard to write that's 'perfect'. I've had the chance to write some fairly technically complicated EVM code (on chain contract upgrades with some other admin features), even the simple lines need a plethora of testing and review. This was a few years ago, but it took myself and another engineer, start to finish a couple months of dedicated effort to write what amounted to something like 5 source files. You have to know how the code executes with extremely high confidence up and down the entire stack, this takes time even with seasoned people. We ended up going through a security review with a third-party team, this is big money to do, high five figures for what amounted to two weeks of code review and pen testing! The problem is, without this serious dedication ($$) to making sure it's as good as you can get, projects are doomed to blow up like this. Hell, who knows what happens in 6 months after release when some EVM level bug gets discovered and directly exposes a hole in your contact. This might be different now, but a lot of contracts back then didn't have anyway to upgrade from those security exploits!

So from my point of view, you have this massive upfront cost, that I suspect the vast majority of teams are not paying, and you also have the chance of success being very low. Where have we seen this before, home automation seems to ring a bell and we've seen the security horror show with that. I don't mean to be such a downer on these projects, but they're really difficult to get right and audit. And when we're talking about putting millions(90!) of dollars into a thing, I don't really want to rely on the goodwill of some hackers to give me my money back. I wish the general public understood the security aspects of these contracts more, but people seem to see these hacks, shrug to themselves thinking they'll get debugged and fixed like normal software, and then continue on in life.

Unfortunately people are going to get burned in crypto by lack of experience, lack of review, lack of investment, and pure and simple scams.

Sounds like introducing some formal methods would be a good way to reduce costs auditing and verification costs. I know there's some work in that area in the Ethereum ecosystem, but I'm surprising it isn't prioritized more.

Case in point. Here's the line of code that introduced a bug in a contract that was ultimately worth $32M:

https://github.com/openethereum/parity-ethereum/blame/4c3217...

https://blog.openzeppelin.com/on-the-parity-wallet-multisig-...

If you look at the associated pull request, it added over 2K lines of code, and removed almost 1K, spread across 20 different files. 5 files have changed so much, GitHub doesn't even show their diff by default.

It was reviewed by one person in a single day.

It's almost like there's a reason banks try not to "move fast and break things"...

Banks break things too, but they typically operate within legal structures (laws, regulations, and contracts) that supersede broken code.

Yes, but banks tend to have policies and procedures in place where large transactions require multiple parties to review and approve. When those procedures get broken, it's usually a result of fraud and appropriate legal actions can be taken.

While DeFi can implement these kind of policies and procedures, the rate at which seemingly undertested (untested?) code is being deployed and given unfettered access to a large values of tokens definitely falls under the "move fast and break things" category. Clearly the people involved don't grasp the level of risks they're taking or there would be a heck of a lot more emphasis on QA over deployment-to-the-blockchain.

banks break things all the time, thats why crypto exists

That’s a pretty glib and incorrect way of explaining crypto’s creation. Really, it was created because of the misguided belief that the fed breaks things, not “banks”. Basically, it was goldbug ideology on steroids.

If we’re comparing who “breaks” things more, crypto or banks, crypto will lose every single time. So far I’ve never had my bank account wiped out and the website replaced with a single page that says “penis”.

Well, not the same way SV does. They did almost break the global economy in 2008, so...

And the government stepped in to save them. Not a fan of that but it's just what happened. Government will not step in to save crypto, at least not yet.

There's also the possibility that governments will actively ignore cryptos problems just to de-enforce crypto's utility.

The repeal of the Glass-Steagall Act in '99 opened the gates for reckless risk-taking. Banks behave nicely only when they're legally obliged to.

> Banks behave nicely only when they're legally obliged to.

Not even then, as repeated illegal actions by banks (Wells-Fargo in particular has been getting caught a lot recently, but is hardly the only offender) demonstrate.

This doesn't look like Javascript to me:

https://twitter.com/Mudit__Gupta/status/1443454935639609345

I see Solidity as statically-typed JS flavour. Knowing all the gotchas, I think it deserves to be called the JS of DeFi. When you write code in it, it feels like walking on a minefield. Except when things go wrong, your frontend won't crash, but you'll lose yours or someone else's money.

Not to mention, you have all sorts of people trying to exploit your code - draining smart contracts from money is a great incentive for black hats.

So it's even worse than JS in some aspects (not just the language itself, but the platform it is tied to).

EDIT: see https://ethernaut.openzeppelin.com/

Solidity is nothing like js. The biggest security issue in js is weird implicit casting and conversions which aren't an issue in solidity. It's definitely the best language to write smart contracts as over the years simple traps have been eliminated, or are at least well known (the worst remaining one comes from people still using .transfer to send eth, but the method is widely known to be obsolete now). What remains is the actual irreducible complexity of writing smart contracts.

The entire compound bug was apparently a typo, > instead of >=. No language can protect against logic errors like that.

How much of this is still applicable?

https://news.ycombinator.com/item?id=14810008

It's almost like there are rules and laws and people in the loop to prevent these kinds of things, and crypto is an expression of naive libertarianism that has no path to implementation without all the same things we decry about fiat - because in the real world those things are useful.

The faster we ban all crypto nonsense the better.

Any code that controls money needs to be super solid, but I wonder if Chia's smart contracts[1] would help? Their VM is functional and doesn't have stateful side effects like Solidity/EVM. The Chia team claims this is more secure/efficient/auditable than arbitrary Solidity code because state changes are often the hardest things to reason about in programs. It's an interesting claim — one that seems like it could be true and is worth seeing if it plays out in reality.

[1] https://chialisp.com

It has nothing to do with the language. It's all about software architecture and logic. Modern JavaScript is one of the best programming languages in existence.

Yikes

Wouldn't a language with built-in support for proving properties of the code be better? My understanding was that compared to most of the typed functional programming languages, idiomatic JavaScript code is terribly more difficult to prove things about, by hand or machine.

Formal proofs are a waste of time. You're more likely to make a mistake in the proof than in the code. How do you prove that the proof sets the right expectations? What is the point of proving that software meets certain requirements if these requirements are the wrong requirements and the problem was solved in the wrong way (the problem was solved, but it was the wrong problem; the user did not need that feature to behave like that)? Coming up with the requirements during implementation is the hard part; that's what most developers get wrong. Implementation is easy.

Formal proofs might even make software worse since they lock down requirements; potentially in a sub-par way. Not to mention that requirements change. Good code needs to be able to handle changing requirements.

Reply on news.ycombinator.com