Hypothetical maximum scale of Eth 1.x

[AlexeyAkhunov]

@lrettig

Block pre-announcement, pre-warming the state (source: @AlexeyAkhunov): 5x

This should already be happening to certain extent - one of the geth’s latest releases effectively included contract storage items into the state caching (I do not have info about Parity, but Turbo-Geth has been doing from the beginning). It means that if you are a miner, and mining a block, but then someone else beat you to it, you need to import your block before you start mining the next one. Since the block you are mining and the one you have imported very likely have almost the same set of transactions, your caches will be warm, and import should be quick.
And that also means (unexpectedly), that this caching actually somewhat penalises miners mining empty blocks.

@lrettig

However, even if we assume, for the sake of argument, that only 10% of these ideas yield fruits, and that those yield only 1% of “advertised” performance/orthogonality, that’s still 1.875 million

I suspect that most of these estimated were made based on the CURRENT state of things, and not on the state of things already improved by other measures, so they would not compound in a straightforward way. I would rather add these numbers than multiply them

EDIT: Addition

@lrettig

To reiterate, the point is not to come up with some specific,. proposed scaling plan for Eth 1x, but rather to consider the question of reinvesting in scaling Eth 1x vs. doubling down on Eth 2 from a high-level, project management perspective.

I support this sentiment (of course I would). I also think that we can make Ethereum 1.0 more changeable (one idea is to make clients simpler by not supporting all historical rules - that would also cut down historical tests - as I described in Backwards-Forwards sync article)