In typical economic analysis if you increase the supply of something (e.g. apples), the price per unit drops. Blockchains seem to behave differently because Metacalfe’s law kicks in: where there’s greater supply, there’s a bigger network effect, which makes the network more desirable and actually increases demand. Unlike in the case of apples, we see that there’s a positive reinforcement loop between supply and demand. This means that there can ultimately be very very high demand for throughput — much more than we might intuitively believe.
Things that probably won’t ultimately be bottlenecks
Proving: seems likely to ultimately be “embarrassingly parallel” thanks to recursive proofs.
Data availability: can be scaled via validium (backed by councils or backed by data availability sampling)
Potential bottlenecks
Sequencer tx processing: Some of the sequencer’s work seems inherently serial.
Bandwidth: Interconnects between multiple sequencers will be limited.
L2 state size
Potential solutions
One solution is to branch off into multiple StarkNet L2s (and/or have L3s), but this would limit synchronous composability which tends to damage network effects, app development velocity, etc.
What’re the options for increasing throughput of the sequencer itself?:
Highly efficient Cairo VM? e.g. in a systems-level language, with JIT, etc?
Parallel tx execution? e.g. test tx (in parallel, across other boxes) to see which slots they read/write to to discover batches that can be executed in parallel?
Maybe could even charge a different amount for tx that are easily parallelizable vs. those that are not.
What other strategies exist? How far can they be taken?
Could you clarify something for me: How can proving be parallel, when as you mention, tx-s in general cannot be executed in parallel? (does the prover sequencer distinction cause this?)
Edit: is the answer that the sequencer executes the transactions as well, so proving can be done in parallel?
Hi Kelemeno!
You are right, paralelizing txs in Ethereum is complicated.
We are considering including “access lists” in order to paralelize transactions - basically, in your tx call, you specify which contracts you’ll have to have access to.
So it allows you to execute in parallel transactions that use distinct sets of contracts.
Does that make sense?
Is it gonna be enforced though? AFAIK Ethereum’s version isn’t enforced but instead incentivized. I think StarkNet is well positioned to enforce it from the very beginning, as we don’t have production workloads running yet.
If it’s not enforced you can’t really make use of it for parallelizing.