The new year is here, and with its arrival, we want to share our thoughts on the 2024 Starknet roadmap!
In four words: fee reduction and performance!
Now some more words, starting with a bit of meta.
Our process started by reflecting on feedback from the ecosystem throughout 2023. We distilled the following points.
-
Content: the ecosystem prioritizes fee reductions and performance improvements.
-
Timeline: builders want more time to develop and less overhead incurred by frequent version upgrades.
-
Communication and transparency:
i. Short term: there should be a fixed, clear, and predictable schedule for upcoming versions.
ii. Mid/long term: there should be an up-to-date document with tentative content and timelines for a few versions forward.
The community’s impact on the roadmap is implicit above, but I want to make it explicit: we think a lot about what you all say and write, and your input plays a key role in version planning and prioritization.
The table you yearn for
Here are the goods! A row-by-row summary follows the table.
| Wen mainnet | Must-have content | Effect | |
|---|---|---|---|
| v0.13.0 | January | v3 transactions, fee reduction, performance improvements | Fee reduction, Performance |
| v0.13.1 | March | EIP4844, stability, rounded-out receipts | Fee reduction, quality of life |
| v0.13.2 | July | Parallelization | Performance |
| v0.13.3 | October (tentative) | Cairo-native (Sierra → MLIR) & L2 gas | Performance |
| v0.14.0 | December (tentative) | Candidates: Volition, applicative recursion, DA compression | Fee reduction |
Starknet v0.13.0 was launched on mainnet last month (January 2024). The first Community Forum post about it outlines support for fee payment in STRK and fee reductions, while the second Community forum post about it focuses on performance improvements, featuring a 4x throughput improvement in erc-20 transfers per second!
Starknet v0.13.1 is coming to integration in a few days, and you can read more about it in this Community Forum post.
Starknet v0.13.2 will introduce optimistic parallelization of execution. Here’s an illustrative example: if tx1 and tx2 interact with disjoint parts of the state, they can be executed concurrently instead of sequentially, saving time. The planned algorithm for Starknet will build on BlockSTM, carefully optimizing every nook and cranny. Concurrent computation is a beautiful field with equally beautiful benefits on the performance in Starknet.
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.
After such massive performance features, you’d understandably want to bask in the warmth of some more fee reductions in this year’s final Starknet version. To this end, we have a few candidate features in mind. It’s too early to decide now, as we’ll be able to make a more educated choice after a few months of EIP4844. Still, we’d like to briefly go over each of the candidate features:
- Volition will facilitate hybrid DA, allowing users to pay less fees by opting to trim the L1 footprint of their transactions.
- Applicative recursion will allow for batching of the L1 footprints of many blocks, leading to better amortization of L1 costs and consequently fee reductions.
- Lastly, DA compression – as the name suggests – will diminish L1 footprints of data, consequently reducing fees.
Caveats you didn’t know you wanted
The most important caveat: in the above table, certainty decreases as you go down the rows: both timeline and the content. We think this is a sensible way to approach a yearly roadmap: the blockchain space is unpredictable and we find ourselves with changing priorities and unexpected engineering challenges. In other words, this post really serves a dual purpose: inform you of the finalized roadmap and timeline for the upcoming two versions, and share our tentative thoughts about subsequent versions. Your input will help us shape the roadmap.
Less crucial but nevertheless very relevant: this brief post does not give a very detailed description of the road to Starknet fee reductions. Such a tale in all its glorious details merits its own post, involving subtleties about fees, the SHARP roadmap, and a cameo by the Starknet Foundation. Stay tuned!
Summary
Looks pretty good don’t it? Looking forward to your comments!
