# Simple Decentralized Protocol Proposal **URL:** \ **Category:** Starknet Technical Development\ **Tags:** protocol, consensus, decentralization, provers, proofs\ **Created:** [August 30, 2023, 11:29pm UTC](https://community.starknet.io/t/simple-decentralized-protocol-proposal/99693 "2023-08-30T23:29:42Z")\ **Posts on this page:** 14\ **Page:** 1
**Author:** ![ilia](https://dub1.discourse-cdn.com/flex005/user_avatar/community.starknet.io/ilia/32/1318_2.png) [@ilia](https://community.starknet.io/u/ilia)\ **Post date:** [August 30, 2023, 11:29pm UTC](https://community.starknet.io/t/simple-decentralized-protocol-proposal/99693/1 "2023-08-30T23:29:43Z")
This post aims to describe a simple complete candidate for a decentralized Starknet protocol. It should be viewed as a proposal for “phase 1” of a gradual evolution that may introduce more sophisticated mechanisms and flows. More specifically, this proposal aims for maximal simplicity under the assumption that more than ⅔ of stake is honest: they follow the protocol without modification. The proposal is structured in five parts: 1. High level overview 2. Time in the protocol 3. The basic processes 4. Recovery mechanism 5. Summary Note this post does not aim to provide specifications. There are many small design choices and optimizations which result in a large variety of different low level descriptions. The goal is to provide a bird’s eye view of the protocol that will encourage the community to cooperate on it, whether by discussion or by creation! For readers who want some background, [here](https://community.starknet.io/t/starknet-decentralized-protocol-i-introduction/2671) is a link to the first of a series of seven posts on decentralization which documents the thought process leading to this proposal. # High level overview We divide the Starknet protocol into four layers: leader/proposer elections, consensus, proving, and L1 state updates. In this section we give a very high level overview of these four layers. 1. L1 staking and leader elections. Starknet will use a leader-based consensus protocol, with proof-of-stake for Sybil resistance. The role of the first layer is to allow people to join and leave the set of stakers, and to allow all L1 full nodes to determine the present stake distribution and upcoming leader schedule. [This previous forum post on leader elections](https://community.starknet.io/t/starknet-decentralized-protocol-ii-candidate-for-leader-elections/4751) gives a good account of the proposal. In this post we elaborate on how exactly slots are defined. 2. L2 consensus. We want to decentralize the block proposal layer from a single proposer to a network of proposers. To ensure this network reaches agreement on the chain, we need a consensus protocol. Starknet will use a variant of Tendermint, which is a leader based PoS consensus protocol. For more information, the [Tendermint paper](https://arxiv.org/abs/1807.04938) is a very lucid source. There is also this forum post on [Tendermint for Starknet](https://community.starknet.io/t/tendermint-for-starknet/98248) which discusses some potential modifications for our context. 3. Proving. Decentralizing the block proposal layer is necessary but insufficient – we must also decentralize the proving layer to [mitigate liveness attacks](https://community.starknet.io/t/starknet-decentralized-protocol-iv-proofs-in-the-protocol/6030#goals-of-prover-decentralization-4). Our proposal is to solve this problem by using a [chained proof protocol](https://community.starknet.io/t/starknet-decentralized-protocol-vii-chained-proof-protocols-braiding/18831), which we sketch now. In a nutshell, the idea (motivated by [Mina](https://docs.minaprotocol.com/node-operators/whats-in-a-block#consensus-state)) is to require every block proposal to also include a proof of a previous block. That way, liveness of the chain is coupled to liveness of the proving layer. The question is “what is the proving job of each proposer”? Here’s the answer. First, divide all of time into a sequence of numbered slots (we will define them in the next section). Next, classify them into k strands by the remainder of the slot number modulo k. [Here’s a picture](https://q.uiver.app/?q=WzAsMjUsWzEsMSwiXFxibGFja3NxdWFyZSJdLFsyLDIsIlxcYmxhY2tzcXVhcmUiXSxbMywzLCJcXGJsYWNrc3F1YXJlIl0sWzQsMSwiXFxibGFja3NxdWFyZSJdLFs1LDIsIlxcYmxhY2tzcXVhcmUiXSxbNiwzLCJcXGJsYWNrc3F1YXJlIl0sWzcsMSwiXFxibGFja3NxdWFyZSJdLFs4LDIsIlxcc3F1YXJlIl0sWzksMywiXFxibGFja3NxdWFyZSJdLFsxMCwxLCJcXGJsYWNrc3F1YXJlIl0sWzExLDIsIlxcYmxhY2tzcXVhcmUiXSxbMTIsMywiXFxibGFja3NxdWFyZSJdLFswLDAsIlxcdGV4dHtzbG90On0iXSxbMSwwLCIxIl0sWzIsMCwiMiJdLFszLDAsIjMiXSxbNCwwLCI0Il0sWzUsMCwiNSJdLFs2LDAsIjYiXSxbNywwLCI3Il0sWzgsMCwiOCJdLFs5LDAsIjkiXSxbMTAsMCwiMTAiXSxbMTEsMCwiMTEiXSxbMTIsMCwiMTIiXSxbNCwxLCIiLDAseyJjb2xvdXIiOlswLDYwLDYwXX1dLFsyLDFdLFsxLDBdLFs0LDNdLFs1LDRdLFs2LDVdLFs3LDZdLFs4LDddLFs5LDhdLFsxMCw5XSxbMTEsMTBdLFszLDAsIiIsMix7ImNvbG91ciI6WzI0MCw2MCw2MF19XSxbNiwzLCIiLDIseyJjb2xvdXIiOlsyNDAsNjAsNjBdfV0sWzksNiwiIiwyLHsiY29sb3VyIjpbMjQwLDYwLDYwXX1dLFs1LDIsIiIsMSx7ImNvbG91ciI6WzEyMCw2MCw2MF19XSxbOCw1LCIiLDEseyJjb2xvdXIiOlsxMjAsNjAsNjBdfV0sWzExLDgsIiIsMSx7ImNvbG91ciI6WzEyMCw2MCw2MF19XSxbMywyXV0=) of 12 slots in three strands. Recall the leader schedule associates a unique leader to each slot, but that a slot may also end without reaching consensus on a new block. Hence slots are potentially empty, like the eighth slot in the picture. Now [the proving rule](https://community.starknet.io/t/starknet-decentralized-protocol-vii-chained-proof-protocols-braiding/18831#first-step-recursive-strands-6): 4. L1 state updates. So far we’ve had leaders collectively agree on a chain of blocks that include proofs. To reach L1 security, we must perform an L1 state update. This procedure requires two things: That’s it! We’ve gone from joining the staker set, to computing the leader schedule, to consensus, to proving, to L1 state updates. # Time in the protocol In this section, we address the vague mentions of time in the protocol. ## Slots Being a [chained proof protocol](https://community.starknet.io/t/starknet-decentralized-protocol-vii-chained-proof-protocols-braiding/18831), it’s best for Starknet to provide each block proposer with enough time, before its turn, to compute the proof required of it. To this end, we want a notion of time that is predictable, easy for sequencers to agree on, persists between blocks, and does not rely on subtle assumptions about clock synchronization. This measurement of time will serve as the foundation for the block proposer schedule (also referred to as leader elections). The [chained proof post points out](https://community.starknet.io/t/starknet-decentralized-protocol-vii-chained-proof-protocols-braiding/18831#naive-attempt-at-chaining-10) the unpredictability of block numbers prevents them from serving as a good foundation in this respect. We need something else. Fortunately, the Tendermint protocol supplies the goods. As mentioned in the [post on Tendermint for Starknet](https://community.starknet.io/t/tendermint-for-starknet/98248), the Tendermint protocol has two intrinsic concepts pertaining to time, namely height and round. The height of a block equals its block number. Within each height there are rounds. After a round without consensus on a new block, the round is incremented. As soon as a block is appended to the chain, the height is incremented and the round resets to zero. Each new round (whether incremented or reset) is the turn of the next proposer. Thus rounds are the foundation for the proposer schedule in Tendermint. A small issue remains: rounds reset when new blocks are appended, so they do not persist. This is easily rectified: maintain an additional counter, called the slot number, which counts rounds without resetting. In Tendermint for Starknet, slots serve as the foundation for the proposer schedule. Remark. We could have avoided the new term “slot” by modifying the round number to persist between blocks. However, it seems reasonable to leave the canonized Tendermint terminology undisturbed, and just introduce a name for what we need. ## Epochs Epochs are the granularity at which Starknet staking operations take effect. They are used for proposer scheduling, as explained in the [leader elections post](https://community.starknet.io/t/starknet-decentralized-protocol-ii-candidate-for-leader-elections/4751). # The high level algorithms ## Monitor The monitor process monitors the L1 state and the Starknet stake distribution. It also calculates the proposer schedule, associating a proposer to every slot. The monitor makes this information available to the other processes. ## Voter The voter executes the Tendermint consensus protocol (participating in P2P, validating, and voting). Here’s a rough overview of the process. 1. Constantly monitor L1: 2. Constantly maintain log of L2 P2P messages. 3. When receive new block: 4. Vote according to the Tendermint state machine. In practice there may be subtle optimizations to avoid unnecessary work, e.g some flows may avoid validating a block if there are too many votes that conflict with it. ## Proposer The proposer process calls the prover as soon as it can, and then waits for the earliest time at which it can start to compute 1. As soon as the previous slot in my strand ends, call the prover with the following job: in the latest non-empty slot in my strand, prove the block of transactions alongside the execution of the verifier program on the preceding non-empty slot in the strand. 2. When I receive the last transaction from the previous proposer’s stream (before consensus): 3. When my block-building window ends, stop building and stream the remaining transaction(s). ## Prover The prover computes the proofs required by the protocol. In this post we consider it a black box. ## Updater The updater process calls the prover to recursively merge strands, and then initiates and performs L1 state updates. 1. As my window of N L1 blocks begins, I use the prover to recursively merge all strands to obtain a proof of a state transition from the current state of Starknet on L1. 2. At n L1 blocks (\tfrac n5 minutes) before the end of my window: # Recovery mechanism Even under the honest majority assumption, bugs in either the sequencer or the prover may result in consensus on a state transition which cannot be proven. For this reason, we will add a recovery mechanism fork choice rule: if there has not been an L1 state update for n L1 blocks, then honest nodes must fork the existing unproven L2 continuation of the L1 state. # Summary This post outlined a complete proposal for a decentralized Starknet protocol. It seems simple enough, and the battle-testedness of Tendermint inspires hope in the protocol’s liveness and security properties. We’d love to hear your feedback to learn of potential concerns, caveats, recommendations, and improvement proposals! ---
**Author:** ![Victormark12](https://dub1.discourse-cdn.com/flex005/user_avatar/community.starknet.io/victormark12/32/3068_2.png) [@Victormark12](https://community.starknet.io/u/Victormark12)\ **Post date:** [September 4, 2023, 8:23am UTC](https://community.starknet.io/t/simple-decentralized-protocol-proposal/99693/2 "2023-09-04T08:23:45Z")
This is actually massive and a positive move in the right direction ---
**Author:** ![tkstanczak](https://dub1.discourse-cdn.com/flex005/user_avatar/community.starknet.io/tkstanczak/32/76015_2.png) [@tkstanczak](https://community.starknet.io/u/tkstanczak)\ **Post date:** [September 4, 2023, 10:53am UTC](https://community.starknet.io/t/simple-decentralized-protocol-proposal/99693/3 "2023-09-04T10:53:26Z")
We would end up paying heavily for the staked capital. Short talk from Jon: [https://www.youtube.com/watch?v=toPd1vgHjVE](https://www.youtube.com/watch?v=toPd1vgHjVE) Blog: [https://dba.mirror.xyz/UTPfxWe65dYrUu\_RJX-5VkAJypFRyw3AZh6m0dRXYZk](https://dba.mirror.xyz/UTPfxWe65dYrUu_RJX-5VkAJypFRyw3AZh6m0dRXYZk) I mostly agree with Jon’s insights and I think everyone who will be deciding on this in Starknet should be aware of the analsysis. ---
**Author:** ![chaskinonchain](https://dub1.discourse-cdn.com/flex005/user_avatar/community.starknet.io/chaskinonchain/32/77079_2.png) [@chaskinonchain](https://community.starknet.io/u/chaskinonchain)\ **Post date:** [October 6, 2023, 12:16am UTC](https://community.starknet.io/t/simple-decentralized-protocol-proposal/99693/4 "2023-10-06T00:16:55Z")
Thank you for posting all of this in public. I’ve really enjoyed going through all seven parts plus the other posts. It’s exciting to watch the decentralization of Starknet be developed in real time with the communities input/feedback Question - Are users provided with a preliminary confirmation immediately after the Tendermint voting concludes, followed by a final confirmation once the merged strand is posted to L1? If so, how long is the expected time interval between these two confirmations, and how is transaction security ensured during this period? ---
**Author:** ![ilia](https://dub1.discourse-cdn.com/flex005/user_avatar/community.starknet.io/ilia/32/1318_2.png) [@ilia](https://community.starknet.io/u/ilia)\ **Post date:** [October 7, 2023, 10:22am UTC](https://community.starknet.io/t/simple-decentralized-protocol-proposal/99693/5 "2023-10-07T10:22:02Z")
@chaskinonchain Howdy! Happy you enjoyed reading! 1. Yes, users will be provided with a preliminary confirmation upon Tendermint consensus, referred to as L2 finality and can be observed by any Starknet node that follows the network, without requiring any execution of transactions. 2. We are aiming toward a block time of no more than 10 seconds at first, so L2 finality will have a similar latency. For the L1 state updates, it’s more difficult to say since latency in the decentralized setting will likely fluctuate with L1 gas prices. For now, the L1 state update latency is several hours. I expect it to stay in the range of at least an hour for at least a year or two. 3. Great question. There are three main security threats: To summarize, L2 finality will have lower latency (seconds vs hours) for the foreseeable future) and lower security than L1 finality. It will be backed by a slashing mechanism meant only for equivocation, and only a permissionless L1 state update mechanism to ensure liveness. Does this answer your questions? ---
**Author:** ![ilia](https://dub1.discourse-cdn.com/flex005/user_avatar/community.starknet.io/ilia/32/1318_2.png) [@ilia](https://community.starknet.io/u/ilia)\ **Post date:** [October 7, 2023, 10:23am UTC](https://community.starknet.io/t/simple-decentralized-protocol-proposal/99693/6 "2023-10-07T10:23:45Z")
@tkstanczak Hey Tomasz! Just to follow-up, we’ve read up on proof-of-governance and will start a round of discussions on it both internally and externally. ---
**Author:** ![chaskinonchain](https://dub1.discourse-cdn.com/flex005/user_avatar/community.starknet.io/chaskinonchain/32/77079_2.png) [@chaskinonchain](https://community.starknet.io/u/chaskinonchain)\ **Post date:** [October 9, 2023, 1:54am UTC](https://community.starknet.io/t/simple-decentralized-protocol-proposal/99693/7 "2023-10-09T01:54:51Z")
Thank you, that answers my questions. I appreciate the depth of your response. On a related note, I’m interested in learning more about the other slashing conditions. Is there a specific resource available that elaborates on this? ---
**Author:** ![ilia](https://dub1.discourse-cdn.com/flex005/user_avatar/community.starknet.io/ilia/32/1318_2.png) [@ilia](https://community.starknet.io/u/ilia)\ **Post date:** [October 9, 2023, 12:37pm UTC](https://community.starknet.io/t/simple-decentralized-protocol-proposal/99693/8 "2023-10-09T12:37:13Z")
I appreciate the depth of the your questions! Regarding slashing - no particular source comes to mind. We’d like to minimize slashing because it may scare off operators. For this reason we prefer to only slash unambiguously intentional offenses, which, ironically, are all equivocation i.e ambiguous behavior. Happy to hear your take on this! ---
**Author:** ![Jommi](https://dub1.discourse-cdn.com/flex005/user_avatar/community.starknet.io/jommi/32/77535_2.png) [@Jommi](https://community.starknet.io/u/Jommi)\ **Post date:** [October 21, 2023, 2:04am UTC](https://community.starknet.io/t/simple-decentralized-protocol-proposal/99693/9 "2023-10-21T02:04:05Z")
I dont see ordering mentioning anywhere outside of “building a block with most profitable transactions from mempool”? It would be important to take this into account, especially as currently ordering differs a lot in different blockchains, from Ethereum’s dynamic gas to Solana’s FIFO. From what I understand, most ORUs currently also operate on FIFO, as well as many tendermint based chains. How will starknet approach this? ---
**Author:** ![ilia](https://dub1.discourse-cdn.com/flex005/user_avatar/community.starknet.io/ilia/32/1318_2.png) [@ilia](https://community.starknet.io/u/ilia)\ **Post date:** [October 22, 2023, 10:11pm UTC](https://community.starknet.io/t/simple-decentralized-protocol-proposal/99693/10 "2023-10-22T22:11:35Z")
Hi @Jommi! I agree the question of ordering txs inside a block is important. For now, Starknet operates in FIFO. However, Starknet will introduce a fee market in an upcoming version. In particular, this fee market will reflect (in a naive way, disregarding MEV) the profitability of each transaction. Thus, (again, disregarding MEV), the sequencer will sort its mempool by profitability and construct its blocks accordingly. Does this answer the question? ---
**Author:** ![Jommi](https://dub1.discourse-cdn.com/flex005/user_avatar/community.starknet.io/jommi/32/77535_2.png) [@Jommi](https://community.starknet.io/u/Jommi)\ **Post date:** [October 23, 2023, 11:10am UTC](https://community.starknet.io/t/simple-decentralized-protocol-proposal/99693/11 "2023-10-23T11:10:04Z")
Thanks for the reply king! I think I understand your point - when describing sucha complex system at an early point we can’t go to the specifics of every single detail, so looking into ordering and MEV right now might be a bit early. However, we should make sure to still keep it in mind, as we can see now in Ethereum how much pain it has caused and how diligently it is being combatted. ---
**Author:** ![byteZorvin](https://dub1.discourse-cdn.com/flex005/user_avatar/community.starknet.io/bytezorvin/32/85152_2.png) [@byteZorvin](https://community.starknet.io/u/byteZorvin)\ **Post date:** [February 6, 2025, 1:11am UTC](https://community.starknet.io/t/simple-decentralized-protocol-proposal/99693/12 "2025-02-06T01:11:06Z")
Hey @ilia, curious if there are any updates on this. Was this take up further or dropped for any reason? ---
**Author:** ![ilia](https://dub1.discourse-cdn.com/flex005/user_avatar/community.starknet.io/ilia/32/1318_2.png) [@ilia](https://community.starknet.io/u/ilia)\ **Post date:** [February 6, 2025, 10:38am UTC](https://community.starknet.io/t/simple-decentralized-protocol-proposal/99693/13 "2025-02-06T10:38:05Z")
Yo @byteZorvin! This protocol is under development as we speak! In 2025 we’ll aim for decentralized consensus and in 2026 I expect we’ll add decentralized proving. You can check out development in the [sequencer repo](https://github.com/starkware-libs/sequencer/) 🙂 ---
**Author:** ![estheroche](https://dub1.discourse-cdn.com/flex005/user_avatar/community.starknet.io/estheroche/32/85345_2.png) [@estheroche](https://community.starknet.io/u/estheroche)\ **Post date:** [March 28, 2025, 12:05am UTC](https://community.starknet.io/t/simple-decentralized-protocol-proposal/99693/14 "2025-03-28T00:05:13Z")
this is a great move and impressive