Hi all, I’m reposting here my SNIP draft PR for laying out the motivation behind a Starknet Security Council. We’ve worked hard during the Starknet “Fête du SNIP” with people from Starkware, Starknet Foundation and the Starknet builder community to come up with the foundations of a Security Council!
Let’s take the conversation here.
Simple Summary
Meta SNIP to lay out the structure, motivation and decisions of the Starknet Security Council.
Today, Arbitrum, Optimism and zkSync have created and are continously improving a security committee, a so-called “Security Council”.
This SNIP answers the network’s strong desire to create a Security Council.
Abstract
A Security Council is a committee of Ethereum L1 (possibly Starknet L2) multi-sig signers. It is empowered to perform certain actions on behalf of the network: Emergency Action and Non-Emergency Actions.
The specific ways in which the Security Council functions are defined by a set of upcoming SNIPs.
Emergency Actions are the last line of defense against bugs and earthshattering events. They are defined in a specific SNIP. Similarly, Non-Emergency actions frame the normal flow of upgrade and lifetime of the network. They are scoped in a specific SNIP. The Starknet Security Council is elected with the help of the Starknet community, the Starknet Foundation, Starkware and the STRK token holders. The election process and composition of the council is described in a subsequent SNIP.
We rely on the following set of resources:
Motivation
Starknet has framed itself as a secure rollup from day 1. This is the core idea behind STARK proofs and the concept of integrity: “do the right thing, even when no one is watching”. While this applies at the protocol level, i.e. for state transitions, it does not apply for actions that fall out of pure programmatic security: how the core smart contracts of the Starknet network get upgraded or who can intervene in case of a bug.
Currently, Starkware operates the Starknet network and oversees its upgrades, as well as emergency processes in case of bug. The Starknet Foundation provides support through diverse “councils” (DeFi Council, Builder Council, etc.). While Starkware acts in good faith and aims to maximize transparency, it remains a single point of failure. Additionally, partly thanks to L2Beats spearheading the effort, the industry is moving towards common security standards. The concept of Security Council paves the way towards sound and standardized processes with regards to network security.
Specification
We suggest a series of 3 SNIPs, one for each important characteristic of the Security Council:
-
Emergency Actions
-
Non-Emergency Actions
-
Election and Composition of the council
Examples and hypothetical future
As a bi-product of the Security Council creation, all upgrades on the Starknet network would be delayed by an amount of time chosen by the Security Council, e.g. 1 month.
Simple minimal examples of how the Security Council could look like (inspired the current states of other rollups):
-
Emergency Actions: the Security Council can reduce the upgrade delay time to zero for an emergency.
-
Non-Emergency Action: the Security Council can vote to accept an upgrade proposed by Starkware.
-
Composition: the Security Council is composed of 12 to 15 people from broad set of sectors (Builders, Users, DeFi, Gaming, Wallet, Cryptography, Infra, etc.), covering a large amount of timezones (always 75% of the council is susceptible to be awake at all time “The Sun never sets on the Security Council”
). Each person in the council has at least 1M vSTRK delegated to them (they must have either skin in the game or a “vote of confidence” from token holders). Council members are reelected by the Starknet Foundation and can be removed by their peers should they misbehave.
Copyright
Copyright and related rights waived via MIT.