Hacker News Reader

Comment by darawk | Hacker News Reader

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

View on HN

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.

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.

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.

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

Reply on news.ycombinator.com