How can StarkNet achieve very high throughput?

Why extremely high throughput matters

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?


Port it to Rust? lolll


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?


Proving is done separately from execution. Execution generates traces. Proving is on traces.

It’s fine that execution is sequential as proving is the slowest part. Parallelizing proving provides the most performance benefits.


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.


Thanks, this makes sense as a narrow form of parallelization. xJonathanLEI’s explanation also makes sense as a wider form. Thanks!

Re: parallelization: starkware may want to investigate this research:

1 Like

A potential solution to this might be what we describe here, I’d love to hear your input!