Starknet Decentralization Roadmap Committed to a Fully Open Source Software Stack

Starknet's Decentralization Roadmap Committed to a Completely Open Source Software Stack

Source: Starkware, Translated by: Songxue, LianGuai

TL;DR

• StarkWare is moving towards decentralization through planning and implementation.

• Ensuring that the Starknet protocol has a clear roadmap for transitioning to a decentralized proof-of-stake protocol.

Introduction

Starknet verifies its state transitions on the Ethereum blockchain by sending its STARK proof, enjoying the security and decentralization provided by Ethereum. This process severely limits the power of centralized entities (such as StarkWare and the Starknet Foundation) in building and maintaining Starknet: centralized entities on the network cannot forge transaction messages, thus misleading or manipulatively manipulating user data or assets.

• Mina Protocol Price Prediction MINA Doubles Overnight – Is This the Next 100x Crypto?
• Cryptocurrency: Breaking the Chains of Finance
• Ledger Launches Ledger Recover: An Adventure in Cloud-based Private Key Recovery

This is the first step in ensuring minimal trust in Starknet and the most crucial step, ensuring that Starknet users do not rely on any centralized party when using the network. However, more measures must be taken to ensure complete minimal trust and decentralization, so that even if entities like the Foundation or StarkWare disappear, the network will continue to operate as planned without interruption. This article outlines the tentative roadmap for the next steps.

Achievements

Less than a year ago, we began documenting our decentralization research process in a series of blog posts, culminating in a simple concrete proposal.

In short, our goal is to transition the operation of the Sequencer+Prover to a decentralized proof-of-stake protocol, where anyone can participate in sequencing and the continued activity of any party is not critical to the network. To do this, there are two necessary processes:

• Implement various components required to run the decentralized protocol;

• Gradually transition operational power to Starknet stakers.

In this article, we will focus on the latter.

Transition Process

In short, the transition process itself has four main threads:

• Transition to a distributed network architecture while the Sequencer operations remain centralized;

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

• Develop an increasingly extensive testing and integration network;

• Promote registration of equity token holders before finally passing the Sequencer operations to proof-of-stake participants.

These numbers represent some obvious sequential dependencies, but there is also a lot of parallel work that can be done. Below is a brief expansion of each thread.

Decentralized Network Architecture

The Starknet network will transition to a more decentralized model:

• Currently, full nodes do not communicate with each other, instead relying on centralized feedline gateways to regularly query the Sequencer.

• In a less centralized model, full nodes will become part of a peer-to-peer network, eliminating the need for a connection between each node and the sequencer.

This kind of change is beyond the scope of network connectivity. Let’s illustrate this with two examples.

First, Sequencer will sign its blocks to alleviate certain trust assumptions and prepare for voting-based BFT protocols with many voters. Second, data propagation will be done in a more distributed manner, 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 the open-source software stack is crucial for enabling everyone to participate in various aspects of the protocol and network. As StarkWare and other contributors implement more components, they will be released for everyone to test, critique, and adapt. Some notable examples (already open-sourced parts in the stack) include full nodes (LianGuaithfinder, Juno, Deoxys), Provers (Stone, Sandstorm), Sequencers (Blockifier, Madara), and block explorers (Starkscan, Voyager, ViewBlock, Stark ComLianGuaiss).

Testing and integration networks: Expanding testing and integration networks are necessary for a smooth transition process. For each new component, it may evolve from an internal testnet to a slightly wider permissioned testnet with external participants and ultimately to a public testnet, integration, and mainnet. Some choices will need to be made later, such as selecting the order in which to introduce test new components and concurrency methods, but that’s a different matter.

Stakers joining: Sufficient time must be given to the L1 staking contract to accumulate enough staking tokens to ensure the decentralized protocol has true economic strength. This is to avoid a situation where a few actors with no real interest maliciously attempt to control Starknet.

Conclusion

In summary, we have roughly outlined the provisional roadmap for the decentralization of Starknet. As with any engineering plan, one of the complexities is that it may evolve and change over time as our contributing builder community develops better insights and understanding.

We will continue to update Blocking; if you have any questions or suggestions, please contact us!