**Reflections on the Decentralized Starknet protocol**

In this post we would like to share some of our thoughts at Nethermindâs Research group around the Starknet Decentralized protocol. For a well organized and systematic presentation of the protocol, we invite you to read Ilia Volokhâs series of posts.

**1. Soft inclusion mechanisms for forced staking updates**

* Context:* The L1 Staking Contract can enforce staking updates on L2 via L1 â L2 messages. These forced updates have a deadline (measured in L1 blocks, around 24h). In the current proposal, when a deadline is reached without L1 receiving a confirmation from L2 of the forced update, honest L2 nodes perform a

*staker reset*(i.e., revert their state to the last accepted block on L1 and reconfigure their staking set to include the stale updates).

Staker resets can affect the latency of the protocol and should be used as a last resort mechanism. Instead of optimistically hoping that forced updates will be included in proposals by altruistic nodes, some soft measures can be taken before the deadlines are reached. We identified two measures that are not mutually exclusive:

**A) Decreasing rewards for blocks containing forced updates.** Proposers who used some of their block space for including forced updates should get rewards for this. We propose a decreasing reward scheme in order to avoid the scenario in which proposers avoid including force updates in order to increase the rewards for them. Decreasing rewards can lead to faster inclusion of the forced updates into blocks.

**B) Engage the consensus mechanism for including forced updates.** Proposed blocks should contain forced updates if available. If a new proposal doesnât contain a forced update (which has a deadline in some epsilon amount of time), during consensus, (honest) nodes will not vote for this proposal. One has to take into account the time it takes for nodes to sync their views of L1, so this mechanism can be engaged after an amount of time in which we are sure that all nodes learned about a new forced transaction.

### 2. Pool of proofs

* Context:* For a block to include txs, it must include a proof for some previous block(s). A block must contain a proof for the latest non-empty block and all intermediary empty blocks in its strand. A proposer is expected to have such a proof to be able to propose a block. Proposers learn in advance when they have to prepare proofs. A proposer can acquire a proof by computing it or by delegation. The protocol offers rewards for blocks and for proofs. The Starknet protocol is using Tendermint as a consensus protocol. We anticipate that proposers for rounds

`0`

for any height will be highly incentivized to acquire such proofs, but not proposers for rounds strictly greater than `0`

.Nodes learn about a proof only when a proposer makes a proposal containing this proof. We identified some drawbacks around this mechanism. For example:

- The proposer who obtained a certain proof can be offline when they are supposed to propose a block, so the computation resources for that proof are wasted.
- Being a proposer for round
`1`

may be a privileged position when it comes to rewards. Suppose in round`0`

, there is a proposal for a valid block`b`

with proof`p`

,`2f+1`

nodes lock on this proposal, but not all nodes commit to it. In this case, the proposer in round`1`

is lucky as they can make the same proposal, reusing the proof`p`

and get the rewards. - Similar with the above situation, (rational) nodes can steal the proofs exposed by previous proposers in order to get rewards. For example, at round
`r`

I receive a`PROPOSAL`

message with block`b`

and proof`p`

. I can collude with others and decide not to lock on`b`

. In the next round I am the proposer. As I donât want to waste computing power to generate a proof, I propose again`(b,p)`

to collect rewards. Note that such a scenario breaks the trust assumption of`2f+1`

honest nodes of Tendermint. - When the upper bound on empty blocks (in a strand) is reached, only a block containing a proof can be proposed. In this case, the consensus protocol will be stuck for a considerate amount of time on a certain height before consensus can be reached on a value, as proposers for rounds greater than
`0`

may not have had enough time to acquire the necessary proof for making a proposal. Moreover, leaders for rounds greater than`0`

have no guarantee that they will get rewards if they acquire a proof, as previous leaders may have already exposed the proof before them.

We think that making a proof a âpublic goodâ as soon as it is computed is a healthy alternative to avoid the above issues. Proofs should be added to a common **pool of proofs** available to all nodes and the entity posting the proof should receive the reward. One disadvantage for having a pool of proofs is that it introduces a new component into the protocol.

One can start computing the proof of a block as soon as the block is committed to the L2 chain. Let us describe what the proof for block `H`

looks like, depending on the type of block.

. The proof for**Block**`H`

is non-empty`H`

is the recursive proof of the followings:- the proof of the execution of the txs in
`H`

- the proof of the verification of the proof in
`H`

- the proof of the execution of the txs in
The proof for**Block**`H`

is empty.`H`

is the recursive proof of the followings:- the proof that block
`H`

is empty - the proof of the previous block in its strand, i.e., block
`H-k`

- the proof that block

With the above mechanism for computing a proof, a proposer for block `H+k`

must include the proof for block `H`

, independently of whether block `H`

is empty or not.

In terms of who is in charge of computing the proofs, we can think of several approaches. The simplest one is the current Proof Scheduling mechanism (i.e., the proposer for round `0`

of height `H`

is in charge for computing the proofs for the previous non-empty block `H-ik`

with `i > 0,`

and all empty blocks `H-jk`

, with `i > j > 0`

, in the strand of block `H`

); note that this approach doesnât solve the above case 4. Alternatively, one can allow a general race or a priority race (in which leaders for all rounds for height `H+k`

have priority on proving block `H`

) for computing proofs, enabling a faster access to proofs.

**Unprovable blocks.** One big concern around the Starknet protocol is due to unprovable blocks. Consensus can be reached on unprovable blocks due to, for example, inconsistencies between execution VMs and provers (e.g., an execution VM used during consensus for validating a block may output that the block is valid due to a bug, but the prover cannot actually prove the block). In such cases, a recovery mechanism must be triggered. In the current design, there is no mechanism for signaling that a block is unprovable. However, the system can recover by employing the reset mechanism used for forced staking updates which can take more than 24h.

A pool of proofs can help dealing with unprovable blocks. The entity who is supposed to provide a proof for a block can submit instead a proof showing that the block is unprovable. For example, if a prover fails to prove the execution of the txs in a block, then the entity can run a prover in a zkVM building a proof showing that the prover failed (and consequently, that the block is unprovable). Even though this mechanism is extremely computational expensive, using it in extreme rare situations can improve the current mechanism for dealing with unprovable blocks.

Resets can also be avoided when identifying an unprovable block. When there is a proof `P`

in the pool showing that block `H`

(already contained in the chain) is unprovable, nodes can treat block `H`

as an empty block (i.e., a block that doesnât change the state) and use the proof `P`

in the recursive proof that will be needed in the next non-empty block.

**3. Decrease the rewards for empty blocks**

* Context:* When they are missing the expected proof for making a proposal, proposers can propose empty blocks.

Even though having the option of proposing empty blocks helps in not slowing down the protocol while waiting for proofs to be computed, it raises other problems For example, malicious/lazy nodes can propose only empty blocks for censoring transactions or for damaging the quality of the chain.

The protocol should discourage nodes for proposing (only) empty blocks when not necessary. A solution around this would be to halve the rewards for consecutive empty blocks proposed by the same node. The first time a node proposes an empty block, the reward should not be halved.

### Summary

With this post, we wanted to point out some problems the Decentralized StarkNet protocol can encounter. We made some suggestions for circumventing them which hopefully can improve the robustness of the protocol. We look forward to hear your feedback on these reflections!