StarkNet continues to evolve, and we gradually shift our gaze towards decentralization. While we expect StarkNet to be decentralized only at the end of the year, it’s not too early to decide on the decentralization scheme.
We did some internal work and currently have several concrete alternatives in mind that we will roll out on subsequent posts in the following weeks.
These approaches reflect different trade-offs one can take in the consensus protocol space. Therefore, before presenting the various proposals, this introductory post will discuss such a protocol’s potential requirements. As no protocol fully meets all the requirements, it is crucial for us to have an active discussion with the community on prioritizing the different desired properties. This discussion would establish a “lens” to compare subsequent concrete suggestions before deep-diving into these suggestions’ details.
But first, why is the problem of decentralizing StarkNet unique?
Different blockchains already present in production a range of levels of decentralization - Ethereum, Bitcoin, Cosmos, Solana, etc. So why is this problem new?
First, while every other decentralized network has only Sequencers, StarkNet has two components: Sequencers (that determine which transactions to execute) and Provers (that prove the correctness of the chosen transactions). A good decentralization approach is required to decentralize the Provers and answer questions like “who can publish proofs”’ or even “when do we publish proofs”? However, an approach that says: “let’s take some consensus algorithm for sequencing, and demand each sequencer to prove what he sequenced” is too naive and creates what we refer to as the "handoff problem.”
The problem is that the rate at which transactions are collected is faster than proving those transactions. For example, the transactions collected from 8:00 to 9:00 may take 5 hours to prove, so the prover commits at 9:00 to its intention to publish the proof, and if it’s honest, it will indeed publish the proof on L1 at 14:00. For transactions collected from 9:00 to 10:00, another prover will commit at 10:00 and then post proof 5 hours later at 15:00, and so on. The sequencers that collect transactions at 9:00 should optimistically assume that the proof will be published. However, the prover may engage in a griefing attack that’d cause their work to be in limbo and perhaps go to waste. Other consensus protocols don’t have a handoff problem because the sequencer’s block is “proven” instantly.
Secondly, StarkNet is an L2 - this means we can rely on L1. The protocol can use L1 as:
- “Public bulletin board” that whatever is written on (and checked) is binding.
- A trusted place that “intervenes” in extreme cases. Imagine, for example, a catastrophic case where 80% of the resources of the protocol are acting maliciously. Regular consensus protocol might fork on such a case. However, with StarkNet, we could use L1 to slash these 80% and continue the network from the last valid place.
What are the ideal requirements for a suitable decentralization protocol?
Any proper decentralization route must provide, at least partially, the following:
-
Permissionlessness - anyone can be a Sequencer or a Prover (given they invest enough resources to it).
-
Assuming rationality, not honesty: Since anyone can participate, the protocol can’t assume parties blindly follow the protocol and enforce correct behavior by explicit checks and economic incentivization.
-
Sufficiently Scalable - the protocol should scale reasonably well, up until a point where we have a reasonably large number of participants. It’s hard to determine what number is “reasonably large.”
-
Strong and Fast L2 Finality - StarkNet state becomes final only after a batch is proven to L1 (which might take as long as several hours today). Therefore, the L2 decentralization protocol should make meaningful commitments regarding the planned execution order well before the next batch is proved.
-
Inexpensive - the users shouldn’t pay excessively high transaction fees to sponsor the work done by the entities (Sequencers and Provers) that run the StarkNet consensus protocol.
-
Lightweight - We want to leave most of StarkNet computational “real estate” for the applicative layer of StarkNet. As an extreme counterexample, a situation where 50% of the Cairo steps proven in each block are dedicated to verifying the consensus protocol itself is wasteful and does not make sense.
We also keep the following nice-to-have requirements in mind:
- As Secure as Ethereum: In “classical” decentralization protocols, an honest/rational majority is required for assuming the network processes correct transactions. However, StarkNet should rely on the security of the underlying L1 network, namely Ethereum. Therefore, a suitable decentralization protocol will guarantee that as long as Ethereum’s security is not compromised, StarkNet will never freeze or enter an invalid state due to an attack on its Sequencers/Provers.
- Battle-tested: StarkWare’s main field of expertise is STARK proofs and the tooling around them, not necessarily consensus protocols. Hopefully, we can utilize components that other consensus protocols that have already demonstrated in production their performance and security, already implemented.
It’s vital to notice that some of these attributes are somewhat conflicting by nature. For example, getting extremely fast finality, or working with dozens of thousands of validators, might result in a protocol that wouldn’t be as lightweight. Another example: relying heavily on underlying Ethereum L1 might cause the protocol to be too expensive. We will work closely with the community to find the right balance.
