Article: StarkWare
Compiled by: Luffy, Foresight News
TL;DR
StarkWare is moving towards decentralization through planning and implementation of two paths;
Starknet has a clear roadmap for transitioning to a decentralized proof-of-stake protocol.
Introduction
Starknet achieves security and decentralization on the Ethereum blockchain by verifying its state transitions through STARK proofs. This process imposes significant limitations on centralized entities (such as StarkWare and the Starknet Foundation) that build and maintain Starknet: centralized entities cannot forge transaction messages, thereby manipulating user data and assets in a fraudulent or misleading manner.
This is the first and most crucial step in ensuring minimal trust in Starknet and ensuring that Starknet users do not rely on any centralized institution while using the network. However, further measures must be taken to ensure complete trust minimization and decentralization, even if entities like the Starknet Foundation or StarkWare disappear, the network will continue to operate smoothly without interruption. This article outlines the tentative roadmap for the next steps.
Current Progress
Less than a year ago, we began documenting our decentralized research process in a series of blog posts, eventually forming a concrete proposal.
In short, our goal is to transition the operations of the prover and verifier to a decentralized proof-of-stake protocol, where anyone can participate in sorting, making anyone's continuous activity on the network non-essential. To achieve this, we will implement two necessary steps:
Implement various components required to run a decentralized protocol;
Gradually transfer operational power 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 keeping the prover's operations centralized;
Ensure the availability of a fully open-source software stack;
Develop an increasingly extensive testing and integration network;
Attract stakers before the final transition of the prover to proof-of-stake.
The numbering represents some obvious sequential dependencies, but a lot of work may be happening simultaneously. Below, we briefly expand on each path.
Decentralized Network Architecture
The Starknet network will move towards a more decentralized model:
Currently, full nodes do not communicate with each other, and each node relies on periodic queries to the prover through a centralized feedback gateway.
In a less centralized model, full nodes will become part of a peer-to-peer network, eliminating the need for each node to connect to the prover.
This change goes beyond network connectivity. Let's illustrate this with two examples.
First, the prover will sign its blocks to reduce some trust assumptions and prepare for the establishment of a vote-based BFT protocol. Second, data propagation will take on a more distributed style, with nodes helping each other synchronize states and complete their local views.
Commitment to a Fully Open-Source Software Stack
Open-source software stack: Ensuring the availability of an open-source software stack is crucial for 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, critique, and adapt. Some notable examples (parts of the stack that have already been open-sourced) include full nodes (Pathfinder, Juno, Deoxys), provers (Stone, Sandstorm), sorters (Blockifier, Madara), and block explorers (Starkscan, Voyager, ViewBlock, Stark Compass).
Testing and Integration Network: Extensive testing and integration networks are necessary for a smooth transition process. For each new component, it may evolve from an internal testnet to a broader permissioned testnet with external participants, and eventually to a public testnet and mainnet. Some choices will need to be made later, such as selecting the order of introducing new components and concurrency approaches.
Attracting Stakers: We must give enough time for the L1 staking contract to accumulate sufficient staking tokens to ensure that the decentralized protocol has real economic strength. This is to avoid situations where a few participants with no actual interest attempt to maliciously control Starknet.
Conclusion
In summary, we have outlined the tentative decentralized roadmap for Starknet. Like any engineering plan, this roadmap may change as our contributor community offers better insights.