5 ms·

Whoa there! Sure Ethereum has it's problems, but going as far as "the people running Ethereum have incredibly bad taste and make poor decisions", displays a hug

Whoa there! Sure Ethereum has it's problems, but going as far as "the people running Ethereum have incredibly bad taste and make poor decisions", displays a huge amount of ignorance towards some incredible engineers who have built a fantastic (and very successful) platform. Ethereum is far more than just the contract language -- it's the distributed consensus system, the merkle-tree backed blockchain, the p2p network, the cryptographic transaction ledger, the virtual machine, and much more. It is way more complex and sophisticated than you're giving it credit for. There have been multiple languages to target the EVM, and they're been getting incrementally better, and will continue to evolve rapidly as more PL experts have gotten involved. So for all the things they've got wrong, they've got lots more right -- and it's only been a bit over two years since the initial release. Give them a break!

UncleMeat 9y ago
The EVM itself is fucked, not just Solidity. It has poorly defined semantics and has a number of strange behaviors that you don't want in high integrity systems.
- DennisP 9y ago
  For example?
  - kevingadd 9y ago
    I would argue that attacks like this https://blog.golemproject.net/how-to-find-10m-by-just-reading-blockchain-6ae9d39fcd95 https://blog.golemproject.net/how-to-find-10m-by-just-readin... are only possible due to the lack of attention paid to safety in the design of EVM. You can compensate for it by putting more smarts into Solidity and other compilers but the basic fact is that the VM doesn't do much to prevent it. Other modern (and even non-modern) VMs take steps to prevent this without reducing expressiveness or speed at all. At a fundamental level, getting 0s when reading missing or out-of-bounds values is an incredible red flag for security-focused design. Incidentally I can't even find a concrete source that says how calldataload behaves when an index is out of bounds. It's not mentioned anywhere in the documentation I've found (on the ethereum website or elsewhere).
  - nokcha 9y ago
    If a function was not designed to be reentrant, then merely sending money to a malicious third-party contract can break the function's intended preconditions and result in a vulnerability. This is exactly what happened with the DAO exploit. http://hackingdistributed.com/2016/06/16/scanning-live-ethereum-contracts-for-bugs/ http://hackingdistributed.com/2016/06/16/scanning-live-ether...
  - UncleMeat 9y ago
    Exception semantics are unclear, requiring explicit checks only in some cases depending on how a function is called.
    - deleted 9y ago
      [deleted]
kevingadd 9y ago
I'm not willing to "give them a break" if they ignored decades of existing academic research and production software to roll their own low-quality packages that actively cost users money through bugs and footguns. Ethereum is not breaking new ground all over the place to the extent that would justify overlooking quality issues, even if it's the first to do particular things. I'm sure the Ethereum ecosystem as a whole contains some clever designs or even good engineering by the people who back it, but that doesn't excuse the fact that they overestimated their competence and their customers are paying for it. It's not "more complex and sophisticated than I'm giving it credit for": I'm giving it "credit" for being too complex and too sophisticated, creating a huge attack surface for security vulnerabilities and lots of space for bugs to dwell because the developers insisted on NIHing things they had no reason to. Complex and Sophisticated is not a good thing in mission-critical software. You want code that is as simple as possible, does the job correctly, and is easy to understand and audit. Complex and Sophisticated is what you write when tackling an incredibly difficult problem or when you're trying to get a promotion. You seem to be confusing the (no personal opinion on this statement) "fantastic and successful" nature of the Ethereum platform with its quality. There's no intrinsic correspondence between success and quality. JavaScript is wildly successful and the experience of using it in 2017 is (thanks to modern tooling and browsers) pretty good, some people might even call it fantastic. But that doesn't erase the long history of defects in the language, defects that people continue to pay for. People invested sweat and blood to turn it into a successful thing. Likewise, sweat and blood is being invested to compensate for Ethereum's numerous deficiencies. Some of those investments were made by the Ethereum developers - props to them - but a lot of that cost is being paid by end users, security researchers, and investors. Tony Hoare calls nulls his 'billion dollar mistake'. How much do you think the cost of Ethereum's numerous design and engineering errors will add up to when all is said and done?
- zeroxfe 9y ago
  Find me a system that does not "actively cost users money through bugs and footguns", and I'll find you something that isn't used. > Complex and Sophisticated is not a good thing in mission-critical software. The complexity of Ethereum comes from the domain. You can hold on to the platitudes. > Complex and Sophisticated is what you write when tackling an incredibly difficult problem or when you're trying to get a promotion. If you don't believe that cryptocurrencies are an "incredibly difficult problem", then, again, you're showing your ignorance. As someone who worked on distributed consensus systems (Paxos) for nearly a decade, I would recommend you pick up a textbook before passing judgement on the nature of this problem. > You seem to be confusing the (no personal opinion on this statement) "fantastic and successful" nature of the Ethereum platform with its quality. Thanks, however, I'm quite familiar with the orthogonal nature of success and quality -- it also turns out that just because it's successful doesn't automatically make it low quality. And really... chill out.

UncleMeat 9y ago

The EVM itself is fucked, not just Solidity. It has poorly defined semantics and has a number of strange behaviors that you don't want in high integrity systems.

DennisP 9y ago
For example?
- kevingadd 9y ago
  I would argue that attacks like this https://blog.golemproject.net/how-to-find-10m-by-just-reading-blockchain-6ae9d39fcd95 https://blog.golemproject.net/how-to-find-10m-by-just-readin... are only possible due to the lack of attention paid to safety in the design of EVM. You can compensate for it by putting more smarts into Solidity and other compilers but the basic fact is that the VM doesn't do much to prevent it. Other modern (and even non-modern) VMs take steps to prevent this without reducing expressiveness or speed at all. At a fundamental level, getting 0s when reading missing or out-of-bounds values is an incredible red flag for security-focused design. Incidentally I can't even find a concrete source that says how calldataload behaves when an index is out of bounds. It's not mentioned anywhere in the documentation I've found (on the ethereum website or elsewhere).
- nokcha 9y ago
  If a function was not designed to be reentrant, then merely sending money to a malicious third-party contract can break the function's intended preconditions and result in a vulnerability. This is exactly what happened with the DAO exploit. http://hackingdistributed.com/2016/06/16/scanning-live-ethereum-contracts-for-bugs/ http://hackingdistributed.com/2016/06/16/scanning-live-ether...
- UncleMeat 9y ago
  Exception semantics are unclear, requiring explicit checks only in some cases depending on how a function is called.
  - deleted 9y ago
    [deleted]

kevingadd 9y ago

I'm not willing to "give them a break" if they ignored decades of existing academic research and production software to roll their own low-quality packages that actively cost users money through bugs and footguns. Ethereum is not breaking new ground all over the place to the extent that would justify overlooking quality issues, even if it's the first to do particular things. I'm sure the Ethereum ecosystem as a whole contains some clever designs or even good engineering by the people who back it, but that doesn't excuse the fact that they overestimated their competence and their customers are paying for it. It's not "more complex and sophisticated than I'm giving it credit for": I'm giving it "credit" for being too complex and too sophisticated, creating a huge attack surface for security vulnerabilities and lots of space for bugs to dwell because the developers insisted on NIHing things they had no reason to. Complex and Sophisticated is not a good thing in mission-critical software. You want code that is as simple as possible, does the job correctly, and is easy to understand and audit. Complex and Sophisticated is what you write when tackling an incredibly difficult problem or when you're trying to get a promotion. You seem to be confusing the (no personal opinion on this statement) "fantastic and successful" nature of the Ethereum platform with its quality. There's no intrinsic correspondence between success and quality. JavaScript is wildly successful and the experience of using it in 2017 is (thanks to modern tooling and browsers) pretty good, some people might even call it fantastic. But that doesn't erase the long history of defects in the language, defects that people continue to pay for. People invested sweat and blood to turn it into a successful thing. Likewise, sweat and blood is being invested to compensate for Ethereum's numerous deficiencies. Some of those investments were made by the Ethereum developers - props to them - but a lot of that cost is being paid by end users, security researchers, and investors. Tony Hoare calls nulls his 'billion dollar mistake'. How much do you think the cost of Ethereum's numerous design and engineering errors will add up to when all is said and done?

zeroxfe 9y ago
Find me a system that does not "actively cost users money through bugs and footguns", and I'll find you something that isn't used. > Complex and Sophisticated is not a good thing in mission-critical software. The complexity of Ethereum comes from the domain. You can hold on to the platitudes. > Complex and Sophisticated is what you write when tackling an incredibly difficult problem or when you're trying to get a promotion. If you don't believe that cryptocurrencies are an "incredibly difficult problem", then, again, you're showing your ignorance. As someone who worked on distributed consensus systems (Paxos) for nearly a decade, I would recommend you pick up a textbook before passing judgement on the nature of this problem. > You seem to be confusing the (no personal opinion on this statement) "fantastic and successful" nature of the Ethereum platform with its quality. Thanks, however, I'm quite familiar with the orthogonal nature of success and quality -- it also turns out that just because it's successful doesn't automatically make it low quality. And really... chill out.