Sequencer roadmap

[greged93]

Below is the draft roadmap for the Kakarot sequencer. Currently divided into 3 stages:

• First a POC with a centralised sequencer running the following improvements over the current RPC solution: mempool, blockifier wrapper with cairo native allowing for EVM database storage.
• Second a testnet stage sequencer, taking as basis the previous POC and advancing it with a proving layer. This exploration phase should allow us to benchmark various DA, proving and verification solutions.
• The last stage will be a decentralisation of the sequencer, focusing mainly on three aspects: mempool gossiping, consensus and proofing.

[ClementWalter]

To make sure I understand correctly:

1. the first PoC is expected to be delivered by the end of the year?
2. the second step is mainly building an in-house proving solution?
3. decentralize everything?

why in stage 2 building this in-house proving block and not using gevulot, sharp or others?

is the expected tech stack built with a framework like madara/substrate or lc/cosmos or from scratch?

how are the expected deadline built? conservative or aggressive? with what team size?

[greged93]

1. Correct
2. Second step is the exploration of proving: should we put our hands in the dirt and build our own highly efficient Kakarot OS, running with Stone/Stwo, or can we delegate this to proving services and expect a good result? I don't have an answer yet so the first ~2 months would be an exploration of the available solutions + evaluation of the difficulty of building our own infra.
3. Decentralise the minimum in order to be able to say "if 99% of the sequencers go down, you can still exit". Could be a model like Solana, permissioned at the start for simplicity and slowly going permissionless.

why in stage 2 building this in-house proving block and not using gevulot, sharp or others?

See point 2.

is the expected tech stack built with a framework like madara/substrate or lc/cosmos or from scratch?

I would be inclined to either build everything ourselves (because the POC is still limited enough for us to be able to do this) or work on using the Katana crates as building blocks. I don't think is Madara is mature enough to start picking from them... On the simplicity aspect, which I believe is what we are aiming for, I think Katana wins.

how are the expected deadline built? conservative or aggressive? with what team size?

Given the current team size and capacity of our team members, we planned for 2 months of maintenance on the RPC which gives us 6 months for the POC sequencer. The three major building blocks are the mempool (for which we have reth/katana for learnings), database (same) and blockifier wrapper. The major unknown is the blockifier wrapper, which is why we left a large amount of time for this.
For the second step, it really depends on what solution we end up going for: in-house proving means we need to scale by a big factor and hire knowledgeable cryptographers. However, given our close relationship with Starkware, we think one year is conservative for in-house proving. If we go for outsourcing, we can probably go a lot faster.
Concerning the third step, this is ballpark: I have never worked on P2P, but would hope that by 2026, Katana/Madara have efficient and clean crates that we can just quickly import and use.

[ClementWalter]

2. prover
   I'm not sure to follow the link between building a kakarotos.cairo and internalize a prover stack inside the sequencer (as opposed to calling an external CairoVM prover). To me, we probably want at some point to build our own main(), which comes in turns with a drop of the blockifier and snos, but I don't see why we should also run our own stone/stwo/platinum instance. I think that we should build something closer Cairo (ie not Starknet related), but not touch the prover infra now. What would be the benefit to do this?

[greged93]

You're right, we got it backwards and thought that modifying the Starknet OS would lead us to a need to run our own prover but these are two separate things indeed. Let me update the drawing to reflect this.

[greged93]

updated

[tcoratger]

After some research today, here's what we could get inspired to start looking at the first step. Good news, Starkware is taking a great new modular approach to its repos that allows us to have visibility into the required components. So we have:

• Mempool level:
  • The Starkware mempool with a new repo under construction: https://github.com/starkware-libs/mempool
  • The reth mempool which we can also draw inspiration from: https://github.com/paradigmxyz/reth/tree/main/crates/transaction-pool
• Committer level:
  • New Starkware repo: https://github.com/starkware-libs/committer
• In terms of literature, this fairly recent paper https://arxiv.org/pdf/2310.03616.pdf describes quite well the roadmap of sequencers towards decentralization. There is in particular the following modular diagram which can inspire us to correctly cut out the elements on the first POC.

About the blockifier this is not 100% clear to me neither but in summary the blockifier is the transaction-executing component of the Starknet stack, in charge of creating state diffs plus blocks. It contains briefly the following components:

• Transaction: verify, execute, deploy account tx
• Block: gas, pre-process
• Concurrency: scheduler
• Execution: hints, contract class,
• Fee
• State