Here's what Vitalik wrote about Ethereum in /r/btc (link: https://np.reddit.com/r/btc/comments/6ldssd/so_no_worries_ethereums_long_term_value_is_still/djt6opz/):
"Ethereum is useless" crowd: Turing completeness is bad! You need decidability for safety!
Us: We don't agree, but if you want decidability here's a decidable HLL on top of ethereum that gives you that: http://github.com/ethereum/viper
EIUC: But we don't need Turing completeness because Post's theorem!
Us: Sure, but it's not about turing completeness, you're missing the whole point of why a richly stateful model like ethereum can do things that a UTXO model can't. Moeser-Eyal-Sirer wallets to start off. Then we can talk about advanced state channel constructions like this, ENS auctions, and so on and so forth.
EIUC: We can do smart contracts too!
Us: Sure, if they're either (i) trivial, or (ii) reliant on a multisig of known intermediaries to actually execute then you can, but not natively.
EIUC: Smart contracts are useless!
Us: ENS auctions have users. Contracts for token sales that implement logic like funding caps have users. Multisig wallets with single-sig daily withdrawal limits have users, and have been a substantial convenience boon for the ethereum foundation itself.
EIUC: Ethereum can't scale!Us: raise the gas limit by 40%
EIUC: No, we mean technical capacity! Like that chart that shows geth nodes take up 150 GB.
Us: First of all, that 150 GB is only true if you full-sync; fast syncing gives you 15 GB. Second, this can be handled with state tree pruning, and if you want it now the Parity client already has it, and takes up only ~10 GB. And by the way, we have a really nice light client that you can run instead of a full node and it has basically the same functionality and thanks to Merkle Patricia state trees it can even directly verify the state of any account without any need for interactive protocols or centralization.
EIUC: But it's not parallelizable!
Us: http://github.com/ethereum/EiPs/issues/98 http://github.com/ethereum/EiPs/issues/648
EIUC: But it's not cacheable!
Us: The version of EIP 648 with full-length address prefixes. And by the way, cacheability only helps reduce stale rates, not initial sync times, and we have an alternative technique to mitigate the practical impact of stale rates, namely the uncle mechanism. And when full proof of stake hits, it'll become okay to have block processing times that are much longer, as long as they can reliably stay under 100% of the block time, and in that case cacheability isn't really all that beneficial in the first place.
EIUC: Proof of stake is fundamentally flawed! Nothing at stake! Stake grinding!
Us: https://github.com/ethereum/wiki/wiki/Proof-of-Stake-FAQ
EIUC: It's still not scalable enough!
Us: https://github.com/ethereum/wiki/wiki/Sharding-FAQAnd so on and so forth.
1
9
2
10
3
11
4
17
18
12
5
19
13
6
20
14
15
16
16
7
8