Starknet v0.13.2 and Roadmap Summer Update

[ilia]

In February, we shared a tentative roadmap for 2024 – a plan of intent.

Over the past months, we have collected extensive feedback from builders to guide and evolve our roadmap.

• By all accounts, the two original goals of fee reduction and performance are sufficiently fulfilled since v0.13.1: transaction fees are extremely low, and Starknet can already sustain over 100 erc-20 transfers a second – more than enough to satisfy current demand.
• In light of the above, it’s time for a new Sheriff in town: UX & devX! Instead of diving into the meta of defining what exactly this means, let’s move to some examples with the beloved table, and elaborate afterward.

	Wen mainnet	Must-have content	Effect
v0.13.2	August	Parallel execution, SNAR & block-packing aiming at 2 sec confirmation time and reduced block time, execute limit will be increased to ≥10M steps	Performance, UX & devX
v0.13.3	October/November	Cairo-native (Sierra → MLIR) & L2 gas; additional feature candidates: nonce channels, try/catch for function call failures	Performance, UX & devX
v0.14.0	January/February	Candidates: Volition, zkThreads, mempool, protocol-level paymaster	TBD

Now some more words.

---

v0.13.2

You send a transaction. You wait for confirmation. You are sad. You don’t want to wait.

Alrighty then! Thanks to applicative recursion on the SHARP front and its complementary Starknet feature – block-packing – v0.13.2 will see reduced block times without increased L1 costs. We aim to reduce block-times until the confirmation time of most transactions averages at around 2 seconds. We expect a block time or somewhere between 20-60 secs. This isn’t a hard commitment yet, but it’s definitely the goal: the leap is delicate from the engineering PoV and we want to test everything is stable before taking blood oaths.

“Ah, but wait”, you say, “Wasn’t this a candidate feature for v0.14.0? How could this be?”

Well…

The effort to improve confirmation time via reduction of block time will further be complemented by parallel execution! Increased throughput means execution will be even faster, driving down confirmation times.

Before moving on to v0.13.3, we should also mention some great work behind the scenes on key aspects of the network, including improvements to streamline work on P2P, and major optimizations to the committer – the service that computes a commitment to the state. These may not sound like chad features, but they contribute a lot to Starknet’s eternally sharpening jawline.

---

v0.13.3

Currently, the only must-have content is Cairo-native. To copy from the first 2024 roadmap post:

Starknet v0.13.3 will feature a joint effort with Nethermind to integrate the state-of-the-art Cairo-native project by LambdaClass into the sequencer. This is some next level @#$% truly state-of-the-art technology. Here’s the story. Currently, the sequencer executes transactions using the Cairo VM (efficiently implemented in Rust by LambdaClass too). The VM effectively emulates another machine, which begs the question: can we circumvent any emulation to improve performance? Turns out the answer is “very very yes” if you’re blessed with a disturbing amount of brainpower. Enter Cairo-native, which lets the sequencer completely bypass the VM and execute native CPU opcodes. Dark magic, you say? Correct! Behind the scenes, Cairo-native is a Sierra→MLIR compiler; the sequencer will use it to compile declared Cairo classes to native bytecode, and run the latter during transaction execution.

The only addition to make now about Cairo-native is to emphasize that faster execution will further improve confirmation times. Alongside it, we mention some more feature ideas that are on the cards for v0.13.3 but yet to be decided.

---

v0.14.0

Everything here is TBD. It’s too early to decide now.

Summary

Huge improvements to confirmation times are coming in v0.13.2, and more improvements to UX and devX are on the menu. Stay tuned and contribute! Got questions? Ask! Got ideas? Suggest! We would love feature ideas from you folks! It can be a cool use-case, a concrete feature, or a vague fantasy. SNIPs are especially welcome!

Cheerio!

[eiki]

Hey @ilia ! Thanks for the write-up, I’m happy to see the 0.13.2 improvements outlined.

I have a few questions:

• why would reduced block time improve confirmation times? What is a “confirmation” in this context? I’m under the impression that confirmations (status=ACCEPTED_ON_L2) are given before the block is mined to users anyway.
• can you explain what is L2 gas?
  it looks like multi-dimensional gas pricing, except it would separate gas in 2D: L1 gas and L2 gas, hinting that L1 gas is related to blob pricing (incurring state diffs + fixed price of the proof verif on L1) and L2 is for pure compute on SN?
  if so, why decide to have L2 gas and not spec multi-dimensional gas directly → you could then price storage vs. calldata differently, c.f. an article on the benefits of multid gas: Multidimensional gas pricing
• I only speak for Kakarot but I believe try/catch for function call failures is a very strong feature for us! It’d def help to have it.

[ilia]

Howdy @eiki!

1. Your impression is correct, but I make the pedagogical distinction between being included in a pending and a closed block. To understand why reduced block times help confirmation times, the key piece of information is a present pecularity in how the sequencer works: there is frequent re-execution of increasingly long initial segments of the tx queue. Shorter block times mean less time for a long queue to accumulate, which in turn precludes length re-executions. Thus we find ourselves with shorter confirmation times.
2. The plan is to have 3 protocol-level resources: L1 gas, L1 data gas (blobs), and L2 gas. We only plan to have a fee market on L2 gas, since that is the resource which becomes scarce in case of congestion. Hence the market will be one-dimensional (at least that’s the current plan). As for “what is L2 gas”, it will be a merger of various resources just as L1 gas: execution, proving, storage, bandwidth…
3. Would be happy to learn more!

[eiki]

The plan is to have 3 protocol-level resources: L1 gas, L1 data gas (blobs), and L2 gas.

What is L1 gas? The marginal incurred cost of a transaction in the L1 verification txs?
What is L1 data gas (blobs)? The marginal participation in posted state diffs in L1 blobs? → this should be paid by people who use storage syscalls no?
What is L2 gas? Whatever is not taken into account by the two above? You mentioned how L2 gas is both about execution and storage → do you mean resp. marginal costs of executing a tx and requiring the sequencer to store additional state?
I think there are talks to split L2 gas in thematic to reduce congestion → C.F VB’s article above linked

[ilia]

L1 gas is the name for Ethereum gas in the Starknet protocol.

Now that DA uses blobs/data gas, the only marginal consumers of L1 gas are L1/L2 messages. There isn’t really a marginal verification cost. You’re correct that users should pay for the storage updates they incur on L1, and they do.

Regarding L2 gas – yes. Also proving costs.

We’re also looking into multidimensional pricing. And by “we” I mean Noam Nisan, who is maybe best suited for this type of question

[eiki]

So:
L1 Gas → L1/L2 messages
L1 Data Gas → cost of blob posting divided among all users
L2 Gas → the rest := proving, storage, calldata, execution (basically the cost of running the sequencer + prover infra)

I guess pricing calldata / execution / storage / proving differently can be addressed down the line, in ~1 year when the research is done!

[ilia]

basically the cost of running the sequencer + prover infra

Note it’s a bit more subtle, since we want to price in some intertia to bombarding the state and having each node keep 15106 TB of data. Storage is an interesting problem!

can be addressed down the line

Yup!

[eiki]

each node keep 15106 TB of data

True! Maybe in the meantime a SNIP to introduce the concept of full node, archive node and light client could be useful, to at least offload the load of every node needing to serve the entire block, transaction and event history

[milan]

We would love feature ideas from you folks! It can be a cool use-case, a concrete feature, or a vague fantasy.

Since you asked for it, I got a crazy vague fantasy feature request:

I’d love to have a way to schedule function execution directly from a smart contract. I obviously don’t have the details figured out, but it would be a way how to say “please execute this function in about 6 hours” and when the time comes, the sequencer would do so.

This has tons of use cases: in DeFi, a protocol could use it to update price feeds from an oracle, automatically rebalancing an AMM position, updating an option vault strategy, etc.; in gaming, it could be used for harvesting asteroids, planting fields, building armies, …

The feature would eliminate the need for a keeper network (which Starknet still does not have) and some pieces of offchain infra we have to build and operate.

I know there’s various security, MEV and other implications, but I believe it’s worth figuring them out as this would be a super valuable feature to have. Looking forward to your comments.

[henri.lieutaud]

Interesting!
The Starkware exploration team worked on a prototype for this during an internal hackathon a while back.
Maybe @abdel can comment on their findings.