• StarkWare is progressing towards decentralization in two threads: planning and implementation.

• A clear roadmap lies ahead for the steps required to ensure the transition of the Starknet protocol to a decentralized proof-of-stake protocol.

Starknet enjoys the security and decentralization provided by Ethereum by sending STARK proofs of its state transitions for verification on the Ethereum blockchain. This flow places substantial limits on the power of otherwise centralized entities building and maintaining Starknet, such as StarkWare and the Starknet Foundation: no centralized entity on the network can forge transaction messages that would misstate or otherwise fraudulently manipulate user data or assets.

This is the first and most critical step in ensuring that Starknet is trust-minimized, and that users of Starknet are not reliant on the honesty of any centralized party when they use the network. However, more must be done to ensure full trust-minimization and decentralization, so that even if entities like the Foundation or StarkWare were to disappear, the network would continue to function as designed and without interruption. This post outlines a tentative roadmap for those next steps.

Just under a year ago, we began documenting our decentralization research process in a long series of blog posts which culminated in a simple concrete proposal.

In short, our goal is to transition operation of the Sequencer+Prover to a decentralized proof-of-stake protocol, whereby anyone can participate in sequencing and such that no party is essential to the continued liveliness of the network. To this end, two necessary threads open:

1. Implementation of the various components required to run the decentralized protocol,

2. A transitional process to gradually decentralize operations to Starknet stakers.

In this post we will focus on the latter.

In a nutshell, the transition process itself has four main threads:

1. Transitioning to a decentralized network architecture while Sequencer operation remains under centralized operation

2. Ensuring the availability of a fully open-sourced software stack

3. Developing increasingly broad testing and integration networks

4. Fostering Staker onboarding in advance of the final transition of Sequencer operation to proof-of-stake participants.

The numbering represents some obvious sequential dependencies, but a lot of concurrent work is possible. Below we slightly expand with a paragraph for each thread.

The Starknet network will move to a more decentralized model:

• At present, full nodes do not communicate with each other, instead each node relies on periodic queries to the Sequencer through a centralized feeder gateway.

• In a less centralized model, full nodes will be part of a peer-to-peer network that does not require a connection between each of them and the Sequencer.

This change goes beyond the connectivity of the network. Let us illustrate this with two examples.

First, the Sequencer will sign its blocks to alleviate some trust assumptions and prepare for a vote-based BFT protocol with many voters. Second, data propagation will take on a more distributed flavor, with nodes helping each other to sync on the state and complete their local view.

Open-Source Software Stack: Ensuring availability of an open-source software stack is critical to enable everyone to participate in the various aspects of the protocol and the network. As more components are implemented, both by StarkWare and by other contributors, they will be released for everyone to test, criticize, and get comfortable with. Some notable examples (of already open sourced parts of the stack) are full nodes (Pathfinder, Juno, Deoxys), Provers (Stone, Sandstorm), Sequencers (Blockifier, Madara), and Block Explorers (Starkscan, Voyager, ViewBlock, Stark Compass)

Testing & Integration Networks: Increasingly broad testing and integration networks are necessary for a maximally smooth transition process. For each new component there will likely be a progression from an internal testnet, to a slightly broader permissioned testnet with external participants, and eventually to a public testnet, integration, and mainnet. There are some choices to be made later, e.g between sequential and concurrent approaches for introducing testing new components, but that’s for another day.

Staker onboarding: We must give time for the L1 staking contract to accumulate sufficient staked tokens to secure the decentralized protocol with real economic weight. This is to avoid a scenario where a small number of participants with little actual skin in the game maliciously attempt to take control of Starknet.

In summary, we have given here a rough overview of the tentative roadmap to decentralizing Starknet. As with any engineering plan, certainly one of this complexity, it is likely to evolve and change over time as our community of contributing builders develops better insights and understanding.

As always, feedback, suggestions, and criticism are welcome. Feel free to reach out on the Starknet community forum!

• StarkWare is progressing towards decentralization in two threads: planning and implementation.

• A clear roadmap lies ahead for the steps required to ensure the transition of the Starknet protocol to a decentralized proof-of-stake protocol.

Starknet enjoys the security and decentralization provided by Ethereum by sending STARK proofs of its state transitions for verification on the Ethereum blockchain. This flow places substantial limits on the power of otherwise centralized entities building and maintaining Starknet, such as StarkWare and the Starknet Foundation: no centralized entity on the network can forge transaction messages that would misstate or otherwise fraudulently manipulate user data or assets.

This is the first and most critical step in ensuring that Starknet is trust-minimized, and that users of Starknet are not reliant on the honesty of any centralized party when they use the network. However, more must be done to ensure full trust-minimization and decentralization, so that even if entities like the Foundation or StarkWare were to disappear, the network would continue to function as designed and without interruption. This post outlines a tentative roadmap for those next steps.

Just under a year ago, we began documenting our decentralization research process in a long series of blog posts which culminated in a simple concrete proposal.

In short, our goal is to transition operation of the Sequencer+Prover to a decentralized proof-of-stake protocol, whereby anyone can participate in sequencing and such that no party is essential to the continued liveliness of the network. To this end, two necessary threads open:

1. Implementation of the various components required to run the decentralized protocol,

2. A transitional process to gradually decentralize operations to Starknet stakers.

In this post we will focus on the latter.

In a nutshell, the transition process itself has four main threads:

1. Transitioning to a decentralized network architecture while Sequencer operation remains under centralized operation

2. Ensuring the availability of a fully open-sourced software stack

3. Developing increasingly broad testing and integration networks

4. Fostering Staker onboarding in advance of the final transition of Sequencer operation to proof-of-stake participants.

The numbering represents some obvious sequential dependencies, but a lot of concurrent work is possible. Below we slightly expand with a paragraph for each thread.

The Starknet network will move to a more decentralized model:

• At present, full nodes do not communicate with each other, instead each node relies on periodic queries to the Sequencer through a centralized feeder gateway.

• In a less centralized model, full nodes will be part of a peer-to-peer network that does not require a connection between each of them and the Sequencer.

This change goes beyond the connectivity of the network. Let us illustrate this with two examples.

First, the Sequencer will sign its blocks to alleviate some trust assumptions and prepare for a vote-based BFT protocol with many voters. Second, data propagation will take on a more distributed flavor, with nodes helping each other to sync on the state and complete their local view.

Open-Source Software Stack: Ensuring availability of an open-source software stack is critical to enable everyone to participate in the various aspects of the protocol and the network. As more components are implemented, both by StarkWare and by other contributors, they will be released for everyone to test, criticize, and get comfortable with. Some notable examples (of already open sourced parts of the stack) are full nodes (Pathfinder, Juno, Deoxys), Provers (Stone, Sandstorm), Sequencers (Blockifier, Madara), and Block Explorers (Starkscan, Voyager, ViewBlock, Stark Compass)

Testing & Integration Networks: Increasingly broad testing and integration networks are necessary for a maximally smooth transition process. For each new component there will likely be a progression from an internal testnet, to a slightly broader permissioned testnet with external participants, and eventually to a public testnet, integration, and mainnet. There are some choices to be made later, e.g between sequential and concurrent approaches for introducing testing new components, but that’s for another day.

Staker onboarding: We must give time for the L1 staking contract to accumulate sufficient staked tokens to secure the decentralized protocol with real economic weight. This is to avoid a scenario where a small number of participants with little actual skin in the game maliciously attempt to take control of Starknet.

In summary, we have given here a rough overview of the tentative roadmap to decentralizing Starknet. As with any engineering plan, certainly one of this complexity, it is likely to evolve and change over time as our community of contributing builders develops better insights and understanding.

As always, feedback, suggestions, and criticism are welcome. Feel free to reach out on the Starknet community forum!