Comment by nemild | Hacker News Reader

Comment by nemild | Hacker News Reader

So far, we have a long way to go to build higher quality code. There's a few reasons:

1. Blockchain smart contracts are often unchangeable, so you can't fix bugs

2. The language is being built as people write code, with some bad design choices that encourage mistakes (slowly being fixed)

3. Libraries are still being developed

4. Tooling is still limited (even basic linting)

5. People are not taking the time to have a beta process.

6. People prematurely optimize gas, at the cost of readability

(For non-Ethereum devs, here's a short tutorial for how the language works: https://learnxinyminutes.com/docs/solidity/ )

My own view is that you have to code expecting that things go wrong, and ensure that your logic survives inevitable mistakes ('resiliency').

There's a lot of great resources on security, for people interested in this space:

Ethereum Safety: https://github.com/ethereum/wiki/wiki/Safety

Decentralized Application Security Project: https://dasp.co/

Consensys Smart Contract Best Practice Guide (I helped coauthor this back in 2016 after the DAO): https://consensys.github.io/smart-contract-best-practices/

Hacking Distributed is a great blog for blockchain security:

http://hackingdistributed.com/

Emin and Phil Daian are great to follow on Twitter:

https://twitter.com/phildaian

https://twitter.com/el33th4xor

Audit Checklist (written by my team): https://github.com/cryptofinlabs/audit-checklist

(Disclosure: Our team does audits for a few projects: http://audit.cryptofin.io/index.html )

Feel free to add other resources to this thread. Imagine it'll be useful for everyone.

> Blockchain smart contracts are often unchangeable, so you can't fix bugs

This is the fatal flaw with smart contracts as a concept.

If they can be changed by the author then they don't provide the security guarantees that make the system worth using, but if they aren't changeable by the author then a huge fraction of smart contracts will ultimately end up doing something unintended because of any of the million reasons we don't normally expect first releases of alpha software to work perfectly in all circumstances.

In a perfect world Etherium would work great, but we don't live in a perfect world. People make mistakes. Any system which expects human input but isn't designed to gracefully handle human error (including the humans who programmed the system) is probably not going to end well.

Changed arbitrarily by the author and immutable are pretty clearly not the only two options. Ethereum lets you design whatever governance scheme you want. You can build a system in which people vote on upgrades, for instance. You can structure that scheme however you want. It's just plain lazy thinking to say "welp code imperfect, therefore we can never use it for important stuff".

Sure hope that system is bug-free.

Yep, it'll take time to converge on high assurance implementations of these schemes. But we will. It is possible to write bug free code, particularly for relatively well defined, small areas.

The whole idea behind smart contracts that code can be law is fatally flawed, because it is a bet on our ability to write bug-free code. We know from experience that this is virtually impossible, especially at large scale, even for the best people and organisations in the world.

This means this ultimately require some form of human arbiter to decide in cases like that, but this ultimately defeats the entire purpose of smart contracts.

Quite. This is a live topic for me. Wiser heads pointed me toward

https://medium.com/@jimmysong/the-truth-about-smart-contract...

when I had my own blockchain moment. I think that immutability and lack of human judgement limit the usefulness of these things. And of course, not everything needs decentralised.

It's worse than that because immutability and lack of human judgement is also the killer feature that smart contracts offer over good old fashioned paper contracts and binding arbitration agreements. Any attempt to make maintaining smart contracts manageable is almost by definition going to undercut one of the main rationales for wanting to use them in the first place.

> The whole idea behind smart contracts that code can be law is fatally flawed, because it is a bet on our ability to write bug-free code. We know from experience that this is virtually impossible, especially at large scale, even for the best people and organisations in the world.

You mean, except for the cases where we do exactly that? Like mars rovers, space shuttles, medical devices, IOT, etc...

Do you see blockchain developers doing the diligence that any random part of the space program does as a reflex?

Absolutely not. The state of blockchain development is shit. My point isn't that it's being done well. My point is that, in theory, it can be done well, and I believe that it can get there, and I think the end goal is worthwhile.

> My point is that, in theory, it can be done well, and I believe that it can get there,

You really mean that eventually smart contracts can be reliable, no bugs, etc? I've seen procurement sign contracts with various unclear wordings in them. I've seen vendors wrongly apply contracts in their rates. It's quite common to have errors in real world contracts. I fail to see how a smart contract would work especially as it's even more complicated.

Smart contracts will not replace complex traditional contracts. They will replace simple ones, especially at first. There will be issues at first, for sure. Over time people will iterate on them and there will be a library of well vetted, well understood, standardized contracts.

Also of note, smart contract does not necessarily mean no human intervention. A smart contract can appeal to an external and possibly human judge/arbitrator.

To assume those code bases don't contain bugs or go through multiple revisions and iterations is just naive. Just because bugs have not been exposed does not mean they are not present.

Smart contracts have people actively snooping and trying to exploit bugs for gain. Oh, and they are publicly accessible.

Also, IOT...pwned many times over ;)

> To assume those code bases don't contain bugs or go through multiple revisions and iterations is just naive.

To assume smart contracts don't go through multiple revisions is equally naive. Now we're arguing about implementation, anyway, which is not the point. Implementation and best practices can be iterated on. The fact that the ecosystem isn't mature yet isn't an argument against getting it there.

I think there's a difference between what you're saying (doing it right is possible) and what the critics are saying (doing it wrong needs to be impossible). There's nothing that best practices can do to prevent a motivated novice from throwing together a minimum effort contract that "works" by whatever test criteria they thought up over the past five minutes.

Imagine surfing the web, but instead of showing a 500 error a broken page would withdraw a random sum from your checking account. It doesn't matter how good the best pages are, no one in their right mind would ever open a browser.

> I think there's a difference between what you're saying (doing it right is possible) and what the critics are saying (doing it wrong needs to be impossible). There's nothing that best practices can do to prevent a motivated novice from throwing together a minimum effort contract that "works" by whatever test criteria they thought up over the past five minutes.

You're absolutely right. There's also nothing to prevent a motivated novice from writing software to control a mars rover. Just, nobody's going to send his rover to Mars. Nothing stops anyone from writing a smart contract, but common sense will (eventually, once the dust settles) stop people from throwing money at them.

a counterpoint: https://en.wikipedia.org/wiki/Mars_Climate_Orbiter

The rovers and shuttles have backup systems with different code in them specifically to deal with coding bugs. These fallback systems have also been repeated needed because of bugs in the shipped system.

You mean like how many smart contracts have reference implementations in other languages?

Being written in other languages is not sufficient. A different algorithm is needed.

I believe the idea is that you write the alternative reference implementation in a language that's easy to computationally reason about (e.g. Haskell) and then try to prove equivalence between your Solidity implementation and that one.

If the algorithm has bugs (and they often do) using the same algorithm in different languages doesn't help.

Sure, but in certain languages you can reason formally about them, and prove properties of them. It's not completely perfect, but particularly for relatively simple models you can get pretty high confidence in correctness, at least, up to certain invariance assumptions.

Proofs have bugs in them, too. Would you bet your life on them? Algorithms are also based on a model of reality. The models are usually wrong, too.

You bet your life on them all the time. Every time you cross a bridge. Medical devices rely on algorithms. The standard of evidence you're requesting here is unreasonable, and not applied in any other domain.

Reply on news.ycombinator.com