When a batch is committed to mainnet, all the tx inside of it become final, I imagine. Is there any faster form of StarkNet finality, even if it’s partia? (Do StarkNet blocks come with any kind of finality guarantees? If not, what is the purpose of StarkNet blocks?)
Given a choice between:
(a) a centralized StarkNet sequencer that promises not to reorder/exclude/lie about intra-batch state
(b) a decentralized sequencer that can reorder/exclude/lie about intra-batch state on the timespan of an entire batch (1-4 hours?)
I’d actually much prefer (a).
Is there any long term plan to reduce time to finality whilst also being decentralized?
32 Likes
“finality” is usually used in the context of trustlessness, so option (a) offers no finality. We can’t really formally distinguish between “L2 finality degrees”, because it is eventually completely up to the operator. I will try to respond with respect to the current implementation of our (centralized) sequencer:
- When a block appears as pending, it will be proved on L1 (up to L1 reorgs).
- Transactions that appear as part of the next block (block hash “pending”) will be part of the next block (up to L1 reorgs and internal errors in our batcher).
The above holds for a sequencer that executes our particular code. In the decentralized phase, where many sequencers operate simultaneously, the above makes no sense and the notion of L2 blocks loses meaning (to see why, consider the naive mechanism which allows the first sequencer that generates a proof to submit a block, then only one L2 block among all the operating sequencers will eventually be part of the canonical chain, so no notion of finality whatsoever).
In the long run, work towards intermediate degrees of finality (with the motivation of reducing latency) is twofold. First, direct work towards decreasing latency by optimizing proof time. Second, designing a protocol whose participants are the different sequencers where the goal is to reach a consensus over the next checkpoint. The latter checkpoint’s finality degree depends on the concrete design. One example would be to publish the checkpoint on L1 and have the StarkNet contract only allow updates that match the latest checkpoint (note that this must involve some checkpoint revert mechanism, and an additional mechanism of choosing the next checkpoint, otherwise the system is completely open to dos attacks).
19 Likes
In the decentralized phase, where many sequencers operate simultaneously, the above makes no sense and the notion of L2 blocks loses meaning
Yes, I had been thinking the same.
We can’t really formally distinguish between “L2 finality degrees”
All finality requires some degree of trust (these are “trust minimized” systems, not “trustless” systems.). Even in e.g. Bitcoin, it’s possible (but unlikely) that the whole community could decide to fork and rewrite history.
I think there’s actually high value even in finality that requires a fairly high degree of trust. For example, Starkware is strongly incentivized to run an honest sequencer because if it came to light that you were reordering/censoring, you would lose a lot of your community.
I’m generally a proponent of Ethereum-level decentralization, but I’d rather delay decentralization of the StarkNet sequencer until there’s a decentralized version that also has fairly fast finality. The UX hit is just too huge otherwise — hour-long finality would be a disaster for many applications.
Second, designing a protocol whose participants are the different sequencers where the goal is to reach a consensus over the next checkpoint… publish the checkpoint on L1
I like this idea.
14 Likes
As for the Alpha phase - StarkNet will have fast finality with the trust guarantees you described in (a) above. I hope that it will be able to provide faster confirmations (on the order of seconds) soon.
As for your question on how we can achieve fast finality even on the decentralized, to add to what @FeedTheFed mentioned -
- Very fast finality - use consensus protocol on small checkpoints. We can use a well known consensus protocol, and achieve the protocols’ finality. It can even be backed by stake.
- Another type of finality is what we described in the checkpoints proposal. The tl;dr is that we can generate a proof to an intermediary state, propagate it off-chain without sending on L1. Full nodes can have an L1 finality since they are ensured this is the correct state (by verifying the proof off-chain) and that they have all the data to update it on L1 if for some reason it is delayed.
We plan to post here the ideas once we have a more mature description of them.
In any case, your feedback on the required finality time when moving to the decentralized phase is very valuable.
14 Likes