I am posting here a diagram that is an outcome of discord discussion with @FeedTheFed about StarkNet transaction lifecycle. It is a documentation of current state of affairs not a design document. Expect changes in the future.
24 Likes
Great diagram! Are the arrows possible transitions? And if so, why is it possible to go backwards? (ie ACCEPTED_ON_L2 → RECEIVED )
14 Likes
- ACCEPTED_ON_L2 → RECEIVED - state update failed due to l1 reorg or sequencer creating invalid proof
- ACCEPTED_ON_L1 → RECEIVED - l2 state rewind due to a deep l1 reorg
- REJECTED → RECEIVED - due to l1 reorg unprovable state might become provable because reorged l1 state might create another set of l1->l2 messages.
I am not sure how transactions that will be canceled by a reorg (I mean there are no corresponding l1->l2 messages after the reorg) should be treated. REJECTED? @FeedTheFed
12 Likes
I was learning about this some time ago as well, came up with this diagram. It’s pretty similar to @maciejka’s but the tx and block statuses are split and I’ve added some more comments (because I forget these things).
10 Likes