7 ms·

It remains a complete embarrassment that Ethereum is based on a home-grown trainwreck of a programming language instead of one of the existing well-supported, b

It remains a complete embarrassment that Ethereum is based on a home-grown trainwreck of a programming language instead of one of the existing well-supported, battle-tested verifiable programming languages out there. Honestly, they could have used C and been better off because of the amount of C verification tools out there - Solidity hardly seems safer than C and its compiler has a history of potentially catastrophic newbie mistakes [1]. Note that some of these bugs are in an optimizer, something a security-focused package handling money shouldn't even need, especially if it risks compromising correctness of the contracts. People talk about Solidity being JS-inspired, but simply using JS would have also been better, because there is verification tooling out there for it, along with compression tooling to make it smaller. And people can use higher-level to-JS compilers like Typescript to get stronger safety assurances if they wish. Any claims that performance justifies the use of a home-grown language are also absurd: High-performance trading firms like Jane Street make use of verifiable functional programming languages like OCaml despite the importance of speed & latency in order to turn a profit. [2] No amount of effort from security researchers is going to completely compensate for the fact that the people running Ethereum have incredibly bad taste and make poor decisions. I remain concerned for people who put their wealth at risk investing in smart contracts because the average contract probably has unnoticed issues. [1] http://solidity.readthedocs.io/en/develop/bugs.html http://solidity.readthedocs.io/en/develop/bugs.html [2] https://www.janestreet.com/technology/ https://www.janestreet.com/technology/

zeroxfe 9y ago
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.
zodiac 9y ago
> Note that some of these bugs are in an optimizer, something a security-focused package handling money shouldn't even need Contract callers pay gas fees to execute the contract so inefficient contracts literally waste transaction fees - if anything optimizers are even more important here. > Any claims that performance justifies the use of a home-grown language are also absurd: High-performance trading firms like Jane Street make use of verifiable functional programming languages like OCaml despite the importance of speed & latency in order to turn a profit "Performance" in the traditional PL sense (eg "OCaml has high performance") also does not carry over directly. In traditional PL perf you'd care about cache, memory, IO, pipeline-friendliness, parallelism, all of which don't carry over to the EVM, where it's all about reducing bytecode instructions count (and hence transaction costs as well as blockchain size). I agree that solidity as a frontend language is prerrt weird and not veey security friendly, and that using a non-solidity frontend is of course feasible, but simply using the whole toolchain of C or OCaml - not so much. These two languages in particular will even need some modification to match Solidity's Event language construct
- kevingadd 9y ago
  You're accepting the assumption/abstraction made by Ethereum here, where "gas" is equivalent to performance, even though gas is an arbitrary measurement. You could easily build your own gas-focused optimizer for a toolchain like llvm or for a compiler like ocaml's. Ethereum could bill contracts based on the actual cycle count they take to execute on the CPU, or some other metric. Then you wouldn't need to use a specialized bytecode designed for the gas system with its own optimizer. Of course, then people would potentially be tuning for the most common CPUs (or ASICs, or whatever) used by miners. But again, it's not necessary to roll your own solution. Consider also whether gas makes any sense in the long run: Compute power continues to increase, and the cost of compute power continues to drop. If smart contracts are really going to be the foundation of a new economy and people are going to build applications on top of them, does gas make that much sense vs billing for actual compute and network resources like AWS or EC2? Is gas even a meaningful abstraction? I'd argue it isn't. If the 'value' of executing contracts in $/gas exceeds the cost of renting AWS/EC2 nodes you're basically created a market for mining arbitrage, and perverse incentives where those miners want to push the prices in one direction. Event-oriented programming is old hat in every modern programming language. C/C++ have plenty of frameworks out there you can use to get at it, so do other languages. In some environments it's the de-facto way to write code. Alternate frontends for the EVM potentially address some issues - which is great - but it doesn't get around the fact that EVM itself is poorly designed, and this is reflected in the system all the way from top to bottom. Some of the errata in the post I linked earlier were ways to exploit design flaws in both the VM and compiler to manipulate contracts, and instead of fixing that in the VM they make you put checking prologues in your functions :/
fsiefken 9y ago
As an alternative you could write your smart contracts with NEO in C#, F#, Java or Kotlin http://docs.neo.org/en-us/sc/introduction.html http://docs.neo.org/en-us/sc/introduction.html
zmonx 9y ago
int_19h has previously posted a nice overview of some of Solidity's flaws: https://news.ycombinator.com/item?id=14810008 https://news.ycombinator.com/item?id=14810008 Such issues make the language extremely error-prone. A possible remedy was also suggested: https://news.ycombinator.com/item?id=14809743 https://news.ycombinator.com/item?id=14809743 Prolog sounds like a great tool for encoding rules, and there has already been some research for encoding legal texts in Prolog.

zeroxfe 9y ago

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.

zodiac 9y ago

> Note that some of these bugs are in an optimizer, something a security-focused package handling money shouldn't even need Contract callers pay gas fees to execute the contract so inefficient contracts literally waste transaction fees - if anything optimizers are even more important here. > Any claims that performance justifies the use of a home-grown language are also absurd: High-performance trading firms like Jane Street make use of verifiable functional programming languages like OCaml despite the importance of speed & latency in order to turn a profit "Performance" in the traditional PL sense (eg "OCaml has high performance") also does not carry over directly. In traditional PL perf you'd care about cache, memory, IO, pipeline-friendliness, parallelism, all of which don't carry over to the EVM, where it's all about reducing bytecode instructions count (and hence transaction costs as well as blockchain size). I agree that solidity as a frontend language is prerrt weird and not veey security friendly, and that using a non-solidity frontend is of course feasible, but simply using the whole toolchain of C or OCaml - not so much. These two languages in particular will even need some modification to match Solidity's Event language construct

kevingadd 9y ago
You're accepting the assumption/abstraction made by Ethereum here, where "gas" is equivalent to performance, even though gas is an arbitrary measurement. You could easily build your own gas-focused optimizer for a toolchain like llvm or for a compiler like ocaml's. Ethereum could bill contracts based on the actual cycle count they take to execute on the CPU, or some other metric. Then you wouldn't need to use a specialized bytecode designed for the gas system with its own optimizer. Of course, then people would potentially be tuning for the most common CPUs (or ASICs, or whatever) used by miners. But again, it's not necessary to roll your own solution. Consider also whether gas makes any sense in the long run: Compute power continues to increase, and the cost of compute power continues to drop. If smart contracts are really going to be the foundation of a new economy and people are going to build applications on top of them, does gas make that much sense vs billing for actual compute and network resources like AWS or EC2? Is gas even a meaningful abstraction? I'd argue it isn't. If the 'value' of executing contracts in $/gas exceeds the cost of renting AWS/EC2 nodes you're basically created a market for mining arbitrage, and perverse incentives where those miners want to push the prices in one direction. Event-oriented programming is old hat in every modern programming language. C/C++ have plenty of frameworks out there you can use to get at it, so do other languages. In some environments it's the de-facto way to write code. Alternate frontends for the EVM potentially address some issues - which is great - but it doesn't get around the fact that EVM itself is poorly designed, and this is reflected in the system all the way from top to bottom. Some of the errata in the post I linked earlier were ways to exploit design flaws in both the VM and compiler to manipulate contracts, and instead of fixing that in the VM they make you put checking prologues in your functions :/

fsiefken 9y ago

As an alternative you could write your smart contracts with NEO in C#, F#, Java or Kotlin http://docs.neo.org/en-us/sc/introduction.html http://docs.neo.org/en-us/sc/introduction.html

zmonx 9y ago

int_19h has previously posted a nice overview of some of Solidity's flaws: https://news.ycombinator.com/item?id=14810008 https://news.ycombinator.com/item?id=14810008 Such issues make the language extremely error-prone. A possible remedy was also suggested: https://news.ycombinator.com/item?id=14809743 https://news.ycombinator.com/item?id=14809743 Prolog sounds like a great tool for encoding rules, and there has already been some research for encoding legal texts in Prolog.