Discussing Starknet roadmap
Introduction
With SN v0.14 hitting mainnet in the coming weeks, we are already scoping and designing the next features. While we continue to work towards decentralization (and a concrete suggestion for the next milestone is available here), we want to expand Starknet’s offering in the following trajectories as well:
- Better Performance: Improve SN cost/throughput and, most notably, block time and finality time (which, starting 0.14, should already become much shorter thanks to the preconfirmed status)
- Offer Unique features: These are things that are possible on SN and not possible on most other chains, most notably EVM chains and/or Solana, and could be a game-changer for dApp builders.
The goal: Getting feedback on priority between these areas, or even surfacing additional features - feedback that will be used as input for the Starknet roadmap (**some features could be ready before decentralized Starknet, which comes on EOY)
Please note: The features detailed here didn’t undergo robust scoping that covers all the edge cases. It could be that a highly sought-after feature is deemed too complex or dangerous from a technical perspective. In this case, you can expect a follow-up update.
Potential Performance improvements
Getting to << 2 seconds blocktime, and reducing preconfirmed latency with Cairo native
This main pain point is currently being prioritized unless other feedback is given. Cairo native means a ~4.5x improvement at execution time of Cairo steps (which also means faster preconfirmation time as it takes less time to execute the transactions). However, enabling Cairo native alone isn’t enough to go from 6 seconds to 1.5-second blocks due to the following reasons:
- Cairo0: Cairo native currently isn’t compatible with Cairo0, and this means that the worst case for blocktime, even after Cairo native, would still be around 6 seconds. To ensure SN gains a shorter blocktime as a result of Cairo native, we need to limit the utilization of Cairo0 per transaction.
- Contracts with Sierra<v1.7: While Cairo native can speed up these contracts, the resource count for these contracts would be inflated. Therefore, a transaction with 10M steps could be counted by Cairo native execution as having 40M Cairo steps (and allowing 40M Cairo steps would nullify all of Cairo native’s advantage)
Thus, to get there, we need to:
- Enable Cairo native: This includes re-enabling it on testnet with the resource count on one sequencer, then enabling it for testnet on all sequencers, then repeat this process on mainnet.
- Limit the number of steps in Cairo0 that a single transaction can perform (in the consensus level, as the number of steps in Cairo0 can’t be proven). For example, enforcing a limitation of at most 2M Cairo0 steps per tx means that Cairo Native can be assumed to work on at least 80% of the largest transactions possible
- Get the ecosystem collaboration to recompile common contracts to Sierra>=1.7. This collaboration is a must-have for transactions with many millions of steps to stay feasible, since after turning Cairo native, the “de facto” barrier for the number of steps with Sierra <1.7 is in the 2-4M steps area (depending on the exact contract/use case)
Change the CASM hashes within SN.
What?
Changing hashes within the Starknet state from Poseidon to Blake. “Starknet state” here refers to the CASM class hashes (used as commitment for the CASM code behind the contracts). Notice that the Sierra class hash (which the on-chain contract may refer to) won’t change the scope of this feature.
Why?
As Starknet moves to its decentralized phase and many sequencers and provers are expected to run, it’s becoming crucial that Starknet’s infrastructure is operated cheaply and efficiently. Moving from Poseidon to Blake offers an order of magnitude difference in the number of hashes that the same proving machine can prove within a set amount of time.
Notice that within each block there is a huge amount of Posiedon hashes, because for each contract access, Starknet OS proves that the CASM executed is indeed the CASM that matches the class hash by proving all the Merkle paths in the block - meaning that this change will cause a significant improvement in proving, and will potentially allow more traffic to fit within a single block.
Potential Unique features
In-protocol Scheduling service
What?
Having a syscall that allows a transaction to trigger another transaction after a time delay. The second transaction will be saved until the prescribed time comes. The syscall will also specify who will pay for this subsequent transaction (with a valid signature). The intention here is to develop this feature at the protocol level and potentially combine it with an in-protocol paymaster to ensure transactions are executed as long as the sender agrees to pay enough. Notice that offchain services (e.g., a Gelato analogue) could offer similar functionality, but more trust is required in the operation of the third party.
Why?
Not having a way to periodically execute logic is a known pain for dApps and users. Users sometimes would love to send transactions periodically, and dApps often have maintenance logic to execute, and since this feature is not there, the dApps do it lazily over other users’ operations.
It’s limiting to the point that full companies like Chainlink and Gelato offer automation services to bridge this gap on other chains.
Stateful validate
What?
Allow validate read-access to a given past block state (of any state of 10 or more blocks ago) and accept or reject the transaction based on it. Accessing past state elements of the referenced block will be under the responsibility of the sequencers (i.e., Merkle paths will not need to be provided by the user).
Why?
Greatly increase the flexibility of wallet logic on SN. SN was the pioneer network of account abstraction, and this feature will enable us to increase further the degrees of freedom in validation, and will enable zklogin in particular, as zklogin refers to Google certificates that are changing periodically (so they can’t be hardcoded and need to be read by the transaction)
Potential downsides
The design decision to assign the sequencer the responsibility of remembering the past state means that too-old blocks may not be referenced because seuqencers are not required to save all past blocks. This, in turn, may cause issues with getting finality and approving blocks with transactions that touch a too-old state.
Forced Transactions
What
Allow any user to submit any transaction on SN from L1. The sequencer must refer to and include this transaction (as accepted or as reverted) within a set amount of time. If the transaction isn’t executed within a set amount of time, anyone could submit a state update that proves this, and only this, transaction validity, and would have a set period to do so.
Why?
Currently, a differentiator for SN vs other rollups is the emphasis on decentralization, trust minimization, and self-custody. While hitting the “stage2” milestone formally seems very far-fetched with the current (and shifting) stage2 definition, this is still a big step forward towards self-custody, which will be acknowledged by key opinion leaders in the self-custody world, such as L2beat, which track the “proposer failure” and “sequencer failure” metrics on their site.
Potential downsides
While mostly theoretical, the period where a forced transaction can be proven by anyone will create a prolonged period (hours, or even days if there is some bug or regulatory constraint abused by the forced transactions’ senders) during which the network could suffer significant reorgs. Such a huge reorg might cause many transactions to be thrown from the mempool and inflict a very bad UX.
During this time, no transaction will get ACCEPTED_ON_L2 status (so status will move directly from “executed” to “accepted on L1”) in order to prevent loss of funds in bridges, off-ramps, etc. (so the bridge-out of SN latency will also increase significantly).
Transient storage
What?
Add a syscall that writes to the state but makes this state element zero at the end of the transaction. This syscall will be cheaper than a regular write as it will cost no l1_data_gas (but it may take more l2_gas than a regular write due to the additional zero writing at the end)
Why?
The goal is mainly to allow information to be passed cheaply between validate and execute endpoints, which currently requires explicitly writing into the contract - making transactions unnecessarily more complicated and expensive (either repeating the calculations or requiring a larger state).