6 ms·

Based on a poor design? according to who? It's the most advanced blockchain out there by far and wide! This was a single contract with a flaw, it's like saying

Based on a poor design? according to who? It's the most advanced blockchain out there by far and wide! This was a single contract with a flaw, it's like saying the whole internet is doomed because some website got a SQL injection.

dkarapetyan 10y ago
I don't think "most advanced blockchain out there" is actual praise. Systems, especially systems that are meant to serve as a substrate for more advanced systems must be simple to understand and reason about. Making the foundation turing complete is indeed poor design.
- heliumcraft 10y ago
  If your goal is a calculator, then a computer is a poor design indeed. Ethereum is meant to be a platform and goes far beyond what Bitcoin can do.
- Retra 10y ago
  Turing completeness is not an implication of poor anything. All it does is remove certain kinds of generality from your proofs. You can still prove things, you just have to be careful stating what the assumptions are.
  - dkarapetyan 10y ago
    So you mean to tell me that taking away the ability to write generic programs to validate contracts is good design? See Rice's Theorem (https://en.wikipedia.org/wiki/Rice%27s_theorem https://en.wikipedia.org/wiki/Rice%27s_theorem). Once you have turing completeness verifying any non-trivial program property starts requiring grad school experience and real proficiency with writing and verifying proofs. Most people, including programmers, do not have the training nor the discipline to actually do what you suggested. In practice the assumptions you mention turn out to be assumptions about totality and termination of certain building blocks and so you are back to a restricted subset of the language which should have been the original language to begin with but instead of automatic verification you have turned the problem into manual labor. Thinking about this more I agree with the naysayers. Etherium was a good experiment to show people what they should not put into a smart contract system.
    - tamana 10y ago
      So instead of hiring a juris doctor lawyer to review my contracts, I'll hire a PhD computer scientist ;)
      - dkarapetyan 10y ago
        Correct. Programmatic contracts should have democratized the entire business but instead this new scheme creates a new class of "lawyer".
        wolfgke 10y ago
        I strongly prefer "laws" that are based on mathematics/computability theory than on social conventions.
        crispyambulance 10y ago
        I think this is the core flaw in the mindset of Ethereum adherents: the very idea that it is even possible to have "Laws" which are completely objective to the point of mathematical logic and that these could/should be enforced, literally, by a computer running a program. We are thankfully very very far from a system of Laws which are anything like that. Such a system might be great in certain "sandbox" environments for manipulating resources that have carefully controlled interactions with the outside. But to have arbitrarily complex "smart contracts" running in the affairs of the real world? no thanks!
        dkarapetyan 10y ago
        We are in agreement. It's unfortunate that the initial implementation was a blunder.
      - wila 10y ago
        .and that PhD computer scientist will have a contract that he/she cannot be held responsible for anything bad that happens with the code he/she writes. Written by a juris doctor lawyer. :)
    - 10y ago
amaks 10y ago
Please read http://hackingdistributed.com/2016/06/17/thoughts-on-the-dao-hack/ http://hackingdistributed.com/2016/06/17/thoughts-on-the-dao.... Solidity language makes very hard to write safe code: Is Ethereum/Solidity Suitable for Secure Smart Contracts? It's clear that writing a robust, secure smart contract requires extreme amounts of diligence. It's more similar to writing code for a nuclear power reactor, than to writing loose web code. Yet the current Solidity language and underlying EVM seems designed more for the latter. Some misfeatures are: A good language for writing state machines would ensure that there are no states from which it is impossible to recover. A good language for writing state machines would make it painfully clear when state transitions can and cannot happen. A good language for maintaining state machines would provide features for upgrading the security of a live contract. A good language for writing secure code would make it clear that there are no implicit actions, that code executes plainly, as read. The current language does not fulfill any of these commandments, and in fact, the last one, involving implicit recursive calls, is what did The Dao in. The SlockIt team even had the designer and implementor of Solidity perform a review of their code. If he cannot get something like The DAO to be secure, no one can.

dkarapetyan 10y ago

I don't think "most advanced blockchain out there" is actual praise. Systems, especially systems that are meant to serve as a substrate for more advanced systems must be simple to understand and reason about. Making the foundation turing complete is indeed poor design.

heliumcraft 10y ago
If your goal is a calculator, then a computer is a poor design indeed. Ethereum is meant to be a platform and goes far beyond what Bitcoin can do.
Retra 10y ago
Turing completeness is not an implication of poor anything. All it does is remove certain kinds of generality from your proofs. You can still prove things, you just have to be careful stating what the assumptions are.
- dkarapetyan 10y ago
  So you mean to tell me that taking away the ability to write generic programs to validate contracts is good design? See Rice's Theorem (https://en.wikipedia.org/wiki/Rice%27s_theorem https://en.wikipedia.org/wiki/Rice%27s_theorem). Once you have turing completeness verifying any non-trivial program property starts requiring grad school experience and real proficiency with writing and verifying proofs. Most people, including programmers, do not have the training nor the discipline to actually do what you suggested. In practice the assumptions you mention turn out to be assumptions about totality and termination of certain building blocks and so you are back to a restricted subset of the language which should have been the original language to begin with but instead of automatic verification you have turned the problem into manual labor. Thinking about this more I agree with the naysayers. Etherium was a good experiment to show people what they should not put into a smart contract system.
  - tamana 10y ago
    So instead of hiring a juris doctor lawyer to review my contracts, I'll hire a PhD computer scientist ;)
    - dkarapetyan 10y ago
      Correct. Programmatic contracts should have democratized the entire business but instead this new scheme creates a new class of "lawyer".
      - wolfgke 10y ago
        I strongly prefer "laws" that are based on mathematics/computability theory than on social conventions.
        crispyambulance 10y ago
        I think this is the core flaw in the mindset of Ethereum adherents: the very idea that it is even possible to have "Laws" which are completely objective to the point of mathematical logic and that these could/should be enforced, literally, by a computer running a program. We are thankfully very very far from a system of Laws which are anything like that. Such a system might be great in certain "sandbox" environments for manipulating resources that have carefully controlled interactions with the outside. But to have arbitrarily complex "smart contracts" running in the affairs of the real world? no thanks!
        dkarapetyan 10y ago
        We are in agreement. It's unfortunate that the initial implementation was a blunder.
    - wila 10y ago
      .and that PhD computer scientist will have a contract that he/she cannot be held responsible for anything bad that happens with the code he/she writes. Written by a juris doctor lawyer. :)
  - 10y ago

amaks 10y ago

Please read http://hackingdistributed.com/2016/06/17/thoughts-on-the-dao-hack/ http://hackingdistributed.com/2016/06/17/thoughts-on-the-dao.... Solidity language makes very hard to write safe code: Is Ethereum/Solidity Suitable for Secure Smart Contracts? It's clear that writing a robust, secure smart contract requires extreme amounts of diligence. It's more similar to writing code for a nuclear power reactor, than to writing loose web code. Yet the current Solidity language and underlying EVM seems designed more for the latter. Some misfeatures are: A good language for writing state machines would ensure that there are no states from which it is impossible to recover. A good language for writing state machines would make it painfully clear when state transitions can and cannot happen. A good language for maintaining state machines would provide features for upgrading the security of a live contract. A good language for writing secure code would make it clear that there are no implicit actions, that code executes plainly, as read. The current language does not fulfill any of these commandments, and in fact, the last one, involving implicit recursive calls, is what did The Dao in. The SlockIt team even had the designer and implementor of Solidity perform a review of their code. If he cannot get something like The DAO to be secure, no one can.