@zaoyang 1/ So stateful scripts don't allow fully parallelizable verification per block because due to race conditions. Two txes in the same block may result in reads/writes from the same contract storage in ways that cannot be predicted from static analysis.
@zaoyang 2/ The more dapps are invoked and the more complex dapps become the worse the problem gets. So without sharding state, ETH verification is more-or-less limited by CPU processing speed.
@zaoyang 3/ So what's in store for CPU scaling? Well, it turns out the Dennard scaling is mostly over (and that's what made Moore's law possible). CPUs won't be expected to become exponentially faster like they were before.
@zaoyang 4/ This is relevant because #ethereum is not well supported by the hardware already. It's orders of magnitude too expensive to support all but a few dapps whose economic value per state change exceeds the tx fee.
@zaoyang 5/ Even if ETH centralizes the architecture, single-core CPU speeds don't get exponentially better by scaling up. If CPU is a bottleneck to syncing this is very bad news for ETH. For their needs, they need the bottleneck to be memory / latency, which has hopes of scaling better.
@zaoyang 6/ So basically the nature of dapps makes tx verification a serial process on #eth. But we're stuck with 3 GHz processors in the foreseeable future due to the end of Dennard scaling. If CPU is a bottleneck for Eth that's bad news.
@zaoyang 7/7 Eth can shard state to help with parallization, but that's a major architectural change. Sharding validation will reduce CPU requirements but at the expense of trust-minimization.
• • •
Missing some Tweet in this thread? You can try to
force a refresh
