<h3>Introduction</h3>Starknet enjoys the security and <a href="https://starkware.co/resource/starknet-decentralization-a-roadmap-in-broad-strokes/" target="_blank">decentralization</a> 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.One of the most critical steps is 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. <h3>How Starknet Got Here</h3>In November 2022, Starknet began documenting their decentralization research process in <a href="https://community.starknet.io/t/starknet-decentralized-protocol-i-introduction/2671" target="_blank">a long series of blog posts</a> which culminated in a <a href="https://community.starknet.io/t/simple-decentralized-protocol-proposal/99693" target="_blank">simple concrete proposal</a>. In short, their goal is to transition operation of the Sequencer+Prover to a decentralized proof-of-stake protocol, where 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. Let’s dig a little deeper into this. <h3>The Transition Process</h3>In a nutshell, the transition process itself has four main threads:1- Transitioning to a decentralized network architecture while Sequencer operation remains under centralized operation2- Ensuring the availability of a fully open-sourced software stack3- Developing increasingly broad testing and integration networks4- 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. <h4>Decentralized Network Architecture</h4>The Starknet network will move to a more decentralized model:<ul><li>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.</li><li>In a less centralized model, full nodes will be part of a peer-to-peer network that does not require a connectionbetween each of them and the Sequencer, eg, a full node will not need to get new blocks from the sequencer, but also from other full nodes in the network.</li></ul> This change goes beyond the connectivity of the network. Let us illustrate this with two examples. <ul><li>First, the Sequencer will sign its blocks to alleviate some trust assumptions.</li><li>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.</li></ul> <h3>Working Towards a Fully Open-Sourced Software Stack</h3>Open-Source Software Stack: Ensuring the 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, Papyrus), Provers (Stone, Sandstorm, LambdaClass prover), Sequencers (Blockifier, Madara), and Block Explorers (Starkscan, Voyager, ViewBlock, Stark Compass, OKlink).Testing &amp; 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. <h3>Conclusion</h3>We have given you 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 Starknet’s community develops better insights and understanding.You can learn more about Starknet and its roadmap to decentralization at <a href="https://community.starknet.io/t/starknet-decentralized-protocol-vii-chained-proof-protocols-braiding/18831" target="_blank">here</a>. <h3>About Starkware</h3><a href="https://starkware.co/" target="_blank">Starkware</a> is a leading blockchain company that specializes in zk-rollup technology and scaling the Ethereum blockchain. Starknet is Starkware’s powerful validity-rollup network that operates on top of Ethereum, bringing scalability, security, and improved security to the blockchain.

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