Starknet reveals decentralization roadmap: gradually decentralizing operational power to network stakers

Original author: StarkWare

Original compilation: Luffy, Foresight News

TL;DR

• StarkWare is moving in the direction of decentralization through planning and implementation of these two paths;

• Starknet’s steps to transition to a decentralized proof-of-stake protocol have a clear roadmap.

introduce

Starknet gains the security and decentralization provided by Ethereum by sending STARK proofs of its state transitions for verification on the Ethereum blockchain. This process imposes significant constraints on the power of the centralized entities that build and maintain Starknet (such as StarkWare and the Starknet Foundation): centralized entities cannot forge transaction messages to misrepresent or otherwise fraudulently manipulate user data and assets.

This is the first and most critical step to ensure that Starknet trust is minimized and that Starknet users do not rely on the integrity of any centralized organization when using the network. However, more must be done to ensure full trust minimization and decentralization, so that even if entities like the Starknet Foundation or StarkWare disappear, the network will continue to operate in an orderly manner without interruption. This article outlines a tentative roadmap for next steps.

Current Progress

Just less than a year ago, we began working on a seriesblog postDocumenting our decentralized research process, we finally formed a simple concreteproposal。 

In short, our goal is to transition the operation of orderers and provers to a decentralized proof-of-stake protocol where anyone can participate in ordering, so that no one is indispensable to the ongoing activity of the network. To do this we will implement two necessary steps:

• Implement the various components required to run a decentralized protocol;

• A transition process to gradually delegate operational authority to Starknet stakers.

In this article, we will focus on the latter.

transition process

In short, the transition process itself consists of four paths:

• Transition to a decentralized network architecture while sequencer operations remain centralized;

• Ensure the availability of a fully open source software stack;

• Develop increasingly broad testing and integration networks;

• Onboard stakers before the sequencer eventually transitions to proof-of-stake.

The numbers represent some obvious sequential dependencies, but a large amount of work may be done simultaneously. Below we briefly describe each path.

Decentralized network architecture

The Starknet network will move to a more decentralized model:

• Currently, there is no communication between full nodes, instead each node relies on periodic queries to the sequencer via a centralized feedback gateway.

• In a less centralized model, full nodes will become part of the peer-to-peer network, without the need for each node to be connected to the orderer.

This change extends beyond network connections. Lets illustrate this with two examples.

First, the sequencer will sign its blocks to reduce some trust assumptions and prepare for the establishment of a voting-based BFT protocol. Second, data dissemination will take on a more distributed style, with nodes helping each other synchronize state and complete their local views.

Committed to a fully open source software stack

Open source software stack: Ensuring the availability of open source software stacks is critical to enabling everyone to participate in all aspects of the protocol and network. As StarkWare and other contributors implement more components, they will be released for everyone to test, criticize, and adapt. Some noteworthy examples (parts of the stack that are already open source) include full nodes (Pathfinder, Juno, Deoxys), provers (Stone, Sandstorm), sequencers (Blockifier, Madara), and block explorers (Starkscan, Voyager, ViewBlock , Stark Compass).

Testing and Integration Network: An extensive testing and integration network is necessary to maximize the smoothness of the transition process. For each new component, there may be progression from an internal testnet to a broader permissioned testnet with external participants, and eventually to a public testnet and mainnet. Some choices need to be made later, such as choosing between a sequential approach and a concurrent approach to introducing new components for testing.

Stakeholder joining: We must give the L1 staking contract enough time to accumulate enough pledged tokens to ensure that the decentralized protocol has real economic strength. This is to avoid the situation where a few participants with no real interests attempt to maliciously control Starknet.

in conclusion

In summary, here we have a rough overview of Starknet’s tentative decentralization roadmap. As with any engineering initiative, this roadmap is subject to change as our contributor community provides better insights.