1/ People have asked me to elaborate on the “verification-not-computation” point. And why Ethereum has a flawed architecture from the get-go.
Thread. 👇
*Note: I use “blockchain systems” to refer to Bitcoin-like blockchains that are based on PoW.
Thread. 👇
*Note: I use “blockchain systems” to refer to Bitcoin-like blockchains that are based on PoW.
2/ First of all, Greg Maxwell explained verification-not-computation concept so well already so I highly recommend reading his full post, linked in @TuurDemeester ’s thread here.
3/ @BobMcElrath also succinctly described the problem here.
4/ Here is my own take.
Bitcoin is no magic. It sacrifices all manners of efficiencies, which goes against our intuition and “best practices”, in order to give us something special.
Bitcoin is no magic. It sacrifices all manners of efficiencies, which goes against our intuition and “best practices”, in order to give us something special.
5/ Bitcoin is specifically inefficient in 2 dimensions:
- It mandates that rate of blocks produced must be slow
- It uses broadcast communication
- It mandates that rate of blocks produced must be slow
- It uses broadcast communication
6/ To highlight how counter-intuitive this is. How often do you:
- Purposely make a job slower, even if you figured out a way to make it faster?
- Tell everyone you know about every single thing that you did, every minute of the day?
- Purposely make a job slower, even if you figured out a way to make it faster?
- Tell everyone you know about every single thing that you did, every minute of the day?
7/ To do this in a network setting is even more insane. Not only you are slow, everyone else must be slow. Not only you scream at everybody, everybody screams at everybody else.
8/ Not only that, this network has hundreds of thousands of members. If you have a giant insane asylum in mind, you have the right mental image. 🙂
Doing things the Bitcoin’s ways is literally insane, in most contexts.
Doing things the Bitcoin’s ways is literally insane, in most contexts.
9/ It turns out that being maximally inefficient has its advantages.
By intentionally forcing things to be slow, Bitcoin makes it costly to cheat. By using broadcast communication, it minimizes the need to trust individual members (or maximize fault tolerance, in CS terms).
By intentionally forcing things to be slow, Bitcoin makes it costly to cheat. By using broadcast communication, it minimizes the need to trust individual members (or maximize fault tolerance, in CS terms).
10/ By doing both, slow blocks & broadcast communication, Bitcoin solves the Byzantine Generals’ Problem. A huge breakthrough in computer science.
11/ But doing things Bitcoin’s ways comes at a heavy cost. It walks a thin line between brilliance and uselessness.
Blockchain systems work well as long as the data flowing through them grow at a _manageable_ rate.
Blockchain systems work well as long as the data flowing through them grow at a _manageable_ rate.
12/ A data growth rate of anything but linear is unsustainable, and a certain death sentence.
Non-linear data growth will quickly kill the individual nodes one-by-one, and inevitably revert the system back to a less trust-minimized model.
Non-linear data growth will quickly kill the individual nodes one-by-one, and inevitably revert the system back to a less trust-minimized model.
13/ As blockchain systems are already maximally inefficient, there is little to fall back on if the data grows too quickly. Blockchain systems, as they are, tread on very thin ice.
14/ So when it comes to blockchain _data_, you need to be ruthlessly efficient. This is to compensate for being maximally inefficient in areas mentioned above.
15/ This is precisely why Ethereum’s architecture of rich “statefulness” is such a bad idea. Ethereum states are needed purely for computation purposes, but they grow at an unmanageable rate.
16/ Ethereum’s design deciscions are even more questionable when the reasons for embracing rich states at the core layer are vague and dubious.
17/ To simulate Turing-completeness?
There can be no real Turing-completeness on the blockchains as all programs must somehow be halted. So “Turing-complete” is a total gimmick. Vitalik himself admitted to this.
There can be no real Turing-completeness on the blockchains as all programs must somehow be halted. So “Turing-complete” is a total gimmick. Vitalik himself admitted to this.
18/ To make programmable smart contracts easier to write?
Ease of use is the least of your worries when it comes to blockchain engineering. Backward priorities. Remember, with blockchains you’re _already_ treading thin ice, without adding rich states.
Ease of use is the least of your worries when it comes to blockchain engineering. Backward priorities. Remember, with blockchains you’re _already_ treading thin ice, without adding rich states.
19/ So why?
To support computations otherwise not possible with Bitcoin-style scripting alone? Not really.
Any “computations” that can be done with ETH smart contracts can be done on Bitcoin, just at a higher layer.
To support computations otherwise not possible with Bitcoin-style scripting alone? Not really.
Any “computations” that can be done with ETH smart contracts can be done on Bitcoin, just at a higher layer.
20/ And this is the crux of the problem. Ethereum is solving problems at the wrong layer and by doing so, needlessly bloating its core design.
21/ Kicking the can down the road and hope difficult problems resolve by themselves is not a solution either.
Sharding is not the solution, as sharding implies scaling down the level of broadcast communication - which is a feature in the context of blockchains, _not_ a bug!
Sharding is not the solution, as sharding implies scaling down the level of broadcast communication - which is a feature in the context of blockchains, _not_ a bug!
22/ Pinning all hope on sharding as the magical cure-all typifies Ethereum’s attitude towards engineering: Hopium.
23/ Ethereum’s problems are even more serious if you consider that Bitcoin, despite it being extremely conservative towards the type of data and growth of data it handles, still has very real chance of failure. IMHO, Bitcoin is very much still an experiment.
24/ If you’ve read my recent article on Bitcoin’s incentive-scheme, you’ll notice that I’ve left a few questions open-ended which I still don't know the answers to.
I’m optimistic on Bitcoin, but cautiously optimistic.
medium.com/@hugonguyen/bi…
I’m optimistic on Bitcoin, but cautiously optimistic.
medium.com/@hugonguyen/bi…
25/ To recap: Bitcoin is already stretching things to the limits to get something useful. Despite this its success is not guaranteed. Ethereum stretches things out much further, without having good justifications. Ethereum’s architecture is flawed from the get-go for this reason.
26/ A few more words on the engineering side of things. The story of Ethereum is actually not uncommon. We’ve seen this movie before:
- RISC vs. CISC in the 70s
- Linux vs. Windows in the 90s
- RISC vs. CISC in the 70s
- Linux vs. Windows in the 90s
27/ In these episodes we’ve learned that hardware/software work best when they are built as modular, simple layers, exemplified by RISC and Linux.
The reason is that these systems tend to be more flexible, more elegant and can adapt easier to changing environments / use cases.
The reason is that these systems tend to be more flexible, more elegant and can adapt easier to changing environments / use cases.
28/ This insight is immortalized in the Unix design philosophy.
“Flexibility, simplicity, and freedom are the foremost considerations”. en.wikipedia.org/wiki/Unix_phil…
“Flexibility, simplicity, and freedom are the foremost considerations”. en.wikipedia.org/wiki/Unix_phil…
29/ The Unix design philosophy also gets a vote of confidence from Nature.
Ant colonies exhibit emergent intelligence even though individually the ants are dumb and highly specialized.
Similarly, our brain is composed of simple neurons that individually perform simple tasks.
Ant colonies exhibit emergent intelligence even though individually the ants are dumb and highly specialized.
Similarly, our brain is composed of simple neurons that individually perform simple tasks.
30/ ETH’s kitchen-sink approach at the core layer bears resemblance to the idea of a complex instruction set. Or the idea of building software out of big, complex components, instead of smaller and more specialized ones.
Complexity for complexity’s sake, not through emergence.
Complexity for complexity’s sake, not through emergence.
31/ A small tangent here is that I've found that Unix design philosophy works equally well in other areas in life. It's not just about designing systems, it's about the way you think. People with complexity tendencies tend to be very... confused.
32/ In summary, Ethereum has questionable design decisions without strong justifications for them. We’ve also seen similar engineering disasters to Ethereum before.
My guess is that Ethereum will eventually be another lesson of what-not-to-dos in the history book.
FIN.
My guess is that Ethereum will eventually be another lesson of what-not-to-dos in the history book.
FIN.
