Hacker News new | past | comments | ask | show | jobs | submit login

I have zero domain expertise in cryptocurrencies or Ethereum, but much experience with unexpected failures of "guaranteed" things and processes.

To use your analogy - I'd view the bridge design engineer as having guaranteed that the design process could not possibly result in construction of a bridge that fails. That seems closer to what Ethereum would have us believe.

A bridge design domain expert presumably understands: - that design process uses strut calculations (and therefore includes measures to guarantee those calculations can never be wrong); - that bridges may be built from steel (and therefore includes inspection routines that guarantee faulty steel can never be used); - that the environment acts on bridges through corrosion and earthquakes (and therefore includes routines that absolutely always preclude failures arising from the bridge's environment); - etc., etc., etc.

Maybe it's just my ignorance or misunderstanding of this domain, but I see Ethereum as naive in its guarantee of perfectly predictable behavior.

A guaranteed flawless protocol that fails (for whatever reason) when implemented in reality, isn't.




In your description I still take away that the root problem isn't in the technology, but in the engineer's implementation. Even a calculation that is guaranteed to produce the correct results [if implemented poorly or with errors or with exclusions] can fail.

The engineer who wrote the contract appears to have made a critical logical error.

That does bring me to your conclusion, though. I've paid less attention to the marketing and promises and have assessed the technology as-is (within the confines of my knowledge) -- as such I see what's possible instead of seeing it as a product that under-delivers.

I wonder if a lot of people (especially on HN) would view it differently if it weren't for such bold claims on the developers' part. I mean, I think you're probably right in it being naive in its guarantee of predictability. I think any actors on the platform should assume its supposedly perfectly predictable behaviour is not quite so when they take to designing software or a contract. But that's part of what I meant when I've said it comes down to engineering practice -- when it comes to critical systems assumptions just shouldn't be made in young technology no matter what anybody tries to sell you.




Join us for AI Startup School this June 16-17 in San Francisco!

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: