SNIPs: process revival


SNIPs (Starknet Improvement Proposals) are the Starknet analogue of Ethereum EIPs. However, in the current state of affairs, there are aspects in which a SNIP differs from an EIP both in its purpose and in its (lack of) processing. As pointed out by the community, little attention has been devoted to the topic over the past few months. The purpose of this text is to revive the SNIP process and propose short-term improvements.

EIP vs SNIP today

The fundamental difference is in handling protocol-level improvement proposals, i.e those which require protocol changes. Ethereum, being decentralized, requires “meta-consensus” on protocol changes among validators and subsequently among client teams. The Ethereum Foundation is a considerable driving force for EIPs, but it does not directly control block proposals. Starknet, in its currently centralized state, strictly requires involvement of the Starknet core teams in StarkWare to implement protocol changes.

Since genesis, almost all protocol-level changes (e.g. version features) have not gone through the full SNIP route, having been decided internally instead. Overall we think this is sensible and justified by the need to move and add features much faster than in Ethereum. That being said, the long term objective is clear: when Starknet is decentralized and mature, the process will closely mirror the Ethereum EIP protocol.

Thus we are left with the question of short-medium term: on the one hand, iterations and versions are still frequent compared to Ethereum. On the other hand, we want to step toward a SNIP process that approaches the “real thing” over time.

Short-medium term proposal

Following SNIP-1, GitHub remains the place to submit SNIPs and is the source of truth for their documentation. Other media are for discussions and “advertising”.

The process

  1. Author submits SNIP.
  2. Following SNIP-1#Editor Responsibilities, the editor performs syntactic checks. If the checks pass then merge to main. Otherwise reject.
  3. After merge to main, the author should change status to review and begin discussions on the community forum, which is the intended domain for discussing SNIPs. The author has edit permissions and is free to modify their proposal at will.
  4. SNIPs enter stale status after 6 months and require an editor (SW) to revive.
  5. An editor can change the status to last call which activates a two week timer. Assuming no other actions, a SNIP in last call status automatically becomes final when the timer runs out.

What does it really mean to finalize?

During the centralized phase of Starknet, finalization has two essential steps: entering the roadmap and running in production. In the decentralized phase, finalization means sufficiently widespread adoption among Starknet operators and full nodes.

What will change now?

The Starknet core teams are committed to much greater responsiveness, both on GitHub and in Community Forum discussions. Specifically, feel free to ping @ilia, @Ohad-StarkWare, @FeedTheFed, and @Leo_L!

What now?

Write SNIPs! :scissors::scissors::scissors:

Great to see this post @ilia! Is it the intention that any snips related to a protocol upgrade will only enter last call two weeks before the network upgrade? Should there be another stage between last-call and final to distinguish between “the community considers this final and it will be implemented” and “the feature is live”?

Also, it’s not clear who the editors are. Probably @ilia, @Ohad-StarkWare, @FeedTheFed, and @Leo_L? Would be good to have this tracked somewhere obvious (not on the snip but on the website?) so the community can push a little for feedback. As long as you don’t get inundated :smiley: