Staking on Starknet voting proposal

[BoazStark]

Staking on Starknet voting proposal

Author: Natan Granit

Introduction

As part of implementing Staking on Starknet (SNIP 18), we propose a community vote on the STRK token minting mechanisms.

We suggested implementing the Staking protocol using a specified minting scheme. Under said scheme, minting will only be done as part of the staking mechanism as outlined below. This proposal does not suggest minting any tokens outside the staking scheme.

The decision to mint STRK tokens as part of the staking protocol is significant and sensitive, warranting thorough community involvement. By involving the community in this decision, we ensure that the process is democratic and aligns with the interests of the token holders. This proposal ensures that new token issuance is directly tied to staking participation rates, thus incentivizing staking while managing inflation effectively.

Vote Details

A vote will be conducted to determine the approval or rejection of the following:

1. The minting mechanism, as elaborated in the subsequent section entitled “Minting Mechanism”
2. The protocol for modifying the parameters of the minting mechanism, as detailed in the subsequent section “Adjustments to Minting Curve”

The goal is to ensure that the minting process is transparent, responsive to staking participation rates, and aligned with the community’s interests.

Minting Mechanism:

We propose the implementation of a minting curve mechanism for new STRK tokens. The minting curve is based on Professor Noam Nisan’s proposal, with a slight parameter variation. The minting curve is defined by the following formula:

M = C/10 * √ S

Where:

• S is the staking rate, expressed as a percentage of the total token supply.
• M is the annual minting rate, also expressed as a percentage of the total token supply.
• C is the maximum theoretical inflation rate, expressed annually as a percentage.

The initial value for C is proposed to be set at 1.6.

Implementing a minting curve mechanism allows for a dynamic adjustment of the token supply in response to staking participation rates. This approach aims to balance the incentives for staking while effectively managing inflation.

Adjustments to Minting Curve:

A monetary committee created by the Starknet Foundation will have the authority to adjust the minting curve constant C within the range of 1.0 to 4.0, subject to the following conditions:

• Lowering C: This adjustment will be made when an excessive amount of STRK is staked.
• Increasing C: This adjustment will be made if insufficient STRK is being staked.

To ensure transparency and community trust, any change to the minting curve constant C must be accompanied by:

• A public announcement detailing the justification for the change.
• The announcement must be made on the community forum at least two weeks in advance of the change.

Conclusion

We believe that this proposal for the STRK token minting mechanism will provide a robust foundation for the first stage of staking on Starknet. We encourage all community members to participate in the vote and share their feedback.

Appendix - Examples:

Staking % of Stakable (1.4B)	Staking % of total supply	Annual minting rate %	Annual rewards rate %
10	1.4	0.19	13.52
20	2.8	0.27	9.56
30	4.2	0.33	7.80
50	7	0.42	6.04
75	10.5	0.52	4.94

[matteo]

Hello @BoazStark & @NatanSW

Thanks for the post. It looks like I’m a little late to the discussion, but I’ll still try to provide my perspective here.

I’m not strongly against anything in this proposal, but I think it lacks ambition. What I get from the staking mechanism is a (well-thought) copy of different L1 designs you studied, from Ethereum to the Cosmos ecosystem. I think it’s a shame that the staking design doesn’t account for what makes Starknet very singular: it’s an L2, with fast proving down the line thanks to Stwo. This means that network operators can’t include incorrect transactions in Starknet’s blocks, and can’t prove false blocks. Which means that trustlessness isn’t correlated to staking: no matter how many sequencers we’ll have, and no matter how much STRK is staked, it won’t affect the fact that transactions included in Starknet blocks are correct.

The staking is only providing credible neutrality and liveness. It’s an incredible strength that we don’t need to pay for economic security, because proving is much cheaper than paying 4-10% to stakers for trustlessness. But what I get from this proposal is that we’re forking L1 designs, even if they have a whole different set of constraints, because they need economic security for trustlessness, but we don’t. If I take the last tab as an example, we’re going to pay something around 0.41 to 0.53% of annual inflation (which would yield between 9.76 to 7.56% to the stakers, and sounds to me like a reasonable assumption for where the market will settle in a high-interest rate environment + no slashing risks) that is currently between $16m and $21m, and this number will grow even more when the locked supply unlocks, with up to 4% of inflation ($160m at current prices). To put that into perspective, both the DeFi committee and the gaming committee have $20m to work with.

I think having a small level of (controlled) inflation is a good thing for the ecosystem, and deflation isn’t the best path forward, but I question the goal of sending this inflation to stakers, who are providing nothing to the protocol. My understanding is that the consensus will support at most 100 operators for the sequencing, which could be subsidized annually by 100*20000 (number of STRK to be staked)*0.4(more or less the current price)*0.1(10% yield)= $80,000 annually. The rest of the inflation could be spent in so many other areas, like liquidity providing for STRK, ecosystem growth, or whatever other area through governance, and not into paying stakers that aren’t providing any economic security because we’re an L2.

Happy to discuss more in depth, but my point is more or less Marcus Buckingham’s words: “You will excel only by maximizing your strengths, never by fixing your weaknesses.” - we don’t have to pay for economic security, it’s our strength so let’s embrace it and actually allocate resources to where it’s needed.

[NatanSW]

Thanks for the detailed and thoughtful comment. Will take some time to contemplate and reply.
cc @ilia

[NatanSW]

Hey @matteo ,
From what you described above, we might ask ourselves why we should decentralise at all. Maybe we only need enough validators but only one sequencer that proves blocks.
This would be problematic because only the consensus on L2 can guarantee L2 finality. Why?
because a sequencer can propose and prove blocks on L2 and, in the end, submit a different proof to L1. In such a case, this malicious sequencer can, for example, off-ramp a lot of funds and receive fiat money but not include this tx in his proof to L1.
The consensus is the extra layer that makes sure that the same proofs were propagated on L2 and sent to L1.

[meison7554]

Are there any contingency plans or mechanisms in place to prevent unintended consequences, such as sharp inflation or deflation, in response to these fluctuations?"

[ilia]

@matteo thank you very much for your measured and thoughtful reply. We will raise your insights and questions internally, and we’ll consult with Noam Nisan who is very well-equipped to think about such questions.

We’ll try to reply within a few days, but please feel very free to ping here in case we don’t.

This constructive criticism is the best kind of feedback

[matteo]

Thanks a lot for the answer @NatanSW
One sequencer isn’t enough that’s for sure, as we wouldn’t have liveness, censorship-resistance, and no guarantee on ordering.
I’m not sure I understood correctly, but let me try to re-phrase so that I make sure of it. The attack would be the sequencer would broadcast a proof + new block to the L2 validators with a tx using an external bridge to bridge out funds, and then not include this tx on the L1? My assumption is that we’ll be able to wait for the hard finality pretty soon with Stwo, and thus external bridges and off ramp will be able to use it without too much problems.
If we don’t think that’s a correct assumption, then we need to find a way to provide better soft finality, but I don’t think that soft finality is a 16m to 160m problem. First, if we have 100 sequencers, running with Tendermint and 20,000 STRK stake, we have an economic security of 20,000 STRK in USD (which would be around USD 7,000) for the soft finality, which would enable fast external bridges for under 7k amount (and we should wait for the hard finality for more). But if we’re not happy with this low amount, we can always increase the stake to let’s say 140k STRK (which is 50k USD - we would have to backtest it, especially find the number of tx above this, but the mean amount of a bridge transaction on Orbiter, which is the #1 external Starknet bridge is 0.16ETH, so far from this number), and thus we can rely on the soft finality for anything under 50k for a total inflation of 100 * 140,000 * 0.4 * 0.1 = $560,000 annualy, which is still at least 28 times less than the staking proposal.

[apoorvsadana]

Just trying to jump into the conversation here to add some of my opinions.

Which means that trustlessness isn’t correlated to staking: no matter how many sequencers we’ll have, and no matter how much STRK is staked, it won’t affect the fact that transactions included in Starknet blocks are correct.

This sounds correct but I would say this is technically true for Ethereum as well. I could have only ONE validator on Ethereum and 1 million full nodes. This validator has complete authority to produce blocks but it’s impossible for it to fool the full nodes into accepting an invalid transaction/block. In this way, the validators on Ethereum are also responsible for only credible neutrality and liveness.

Extending this argument, in my opinion, the correct mental model for economic security is to look at it as a security budget that can be slashed in case of liveness failures that come from malicious validators. So 1/3rd of total stake must be greater than the loss that occurs in the event of a liveness failure. This holds true for both L2s and L1s. However, with that being said, I would like to say that this topic is commonly debated in the web3 community under the theme “economic security is a meme”

My assumption is that we’ll be able to wait for the hard finality pretty soon with Stwo

I think Stwo will increase proof generation speed and consequently make proofs available faster on the L2 p2p network. However, settling on L1 would still need to wait for more time to aggregate proofs and amortize settlement cost across multiple transactions. However, there might be ways to make this better by sending proofs in blobs before actually verifying them.

Happy to hear your thoughts!

[ilia]

@apoorvsadana I agree with everything you have written!

@matteo, our analysis is a bit different than yours.

First, I agree with the conceptual separation between safety and liveness, but I don’t think proofs are a magic solution here. Blockchain safety has two facets: validity of state transitions, and network consistency. Proofs give succinct verification, but they do not preclude equivocation of valid conflicting chains. Note this type of equivocation includes the basic “double spend” where Alice gives Bob tokens on chain A but not on chain B.

As you say, the a prefix of the Starknet ledger is eventually proven on L1. But the non-negligible latency until L1 finality will not be magically reduced by Stwo. Latency stems from the high L1 verification cost, which motivates us to aggregate demand and batch proofs (as remarked by Apoorv). This (currently) high latency also makes the L2 security very interesting. If L1 finality took 𝜖 time, and you assume L1 is secure, then you’d truly only care about L2 liveness. Assuming some forced transaction mechanism, this reduces to another thing Apoorv mentioned: just imagine you’re an Ethereum user.

Now on to security. The key type of attack in our mind is: the stakers short STRK and then sabotage the network. Sabotage can violate safety, liveness, or both. Each is a significant enough attack vector to say that we want the network operators to have a non-negligible percent of the network’s value at stake. Noam wrote about this in §3.5 here. So perhaps the target % of staked funds can be lower in Starknet compared to Ethereum, but we think it should still be a non-negligible %.

Sorry if I rambled. Happy to continue the discussion!

[matteo]

Great to have your thoughts Apoorv!

I could have only ONE validator on Ethereum and 1 million full nodes. This validator has complete authority to produce blocks but it’s impossible for it to fool the full nodes into accepting an invalid transaction/block. In this way, the validators on Ethereum are also responsible for only credible neutrality and liveness.

I’m not sure I understand your point, as far as I understand it full nodes can’t take part in the consensus, if a malicious block is introduced they can do nothing but notice it.

This would mean that 51% attacks are not possible on a POS.

Extending this argument, in my opinion, the correct mental model for economic security is to look at it as a security budget that can be slashed in case of liveness failures that come from malicious validators.

I agree that it’s what we’re looking at for Starknet and L2s: how to prevent liveness failures. I don’t have any better solution, but my point is that we’re an L2 and we have to pay the exact same price in inflation as an L1 for liveness, then why are we an L2 to begin with? Again I have no better solution, but paying 16-160m annually for liveness doesn’t seem like good capital allocation.

However, there might be ways to make this better by sending proofs in blobs before actually verifying them.

Agreed, we would need a trustless way to verify that the final proof settled really corresponds to the ones published in the blobs and I have no idea if it’s possible.

[matteo]

Thanks a lot for the reply Ilia!

I will detail more on the few points but the TLDR is: why are we an L2? We’re paying the inflation for validators, people care about the Starknet (soft) finality, there’s a consensus: what’s the purpose of being verified on L1? I understand that the trust minimized bridge to Ethereum is a good thing, proofs are good for light and full nodes to sync faster etc, but none of this is tying us to being an L2.

Proofs give succinct verification, but they do not preclude equivocation of valid conflicting chains.

Agreed, but this is a soft finality problem. The valid chain is the one verified on Ethereum.

But the non-negligible latency until L1 finality will not be magically reduced by Stwo. Latency stems from the high L1 verification cost, which motivates us to aggregate demand and batch proofs (as remarked by Apoorv).

I got too optimist on this part🥲

Sabotage can violate safety

What’s the definition of safety here? I don’t understand how validators can violate safety

the stakers short STRK and then sabotage the network.

To the best of my understanding, validators can only attack the liveness of the network - if they try to add malicious transactions the network will just stop. I’m playing the devil’s advocate here, but I also don’t see any evidence showing that liveness failure impact the performance of the token. It happened with Solana for instance on the 6th of February 2024 the daily candle is green, and the 25th of February 2023 the daily candle is red -2%.

Noam wrote about this in §3.5 here.

I very much agree with what is written in this article, but again for an L1. As an L2 the security of the platform isn’t tied to the market cap of the token, and thus only liveness can be hurt under the current model.

Is it possible to reduce the latency between the soft and hard finality drastically, or is it a dream?

[apoorvsadana]

Thanks for the response @matteo @ilia! And sorry for this long post, I was mostly trying to lay down a mental model for myself when writing it down

I’m not sure I understand your point, as far as I understand it full nodes can’t take part in the consensus, if a malicious block is introduced they can do nothing but notice it.

But if the block is invalid the full node will reject it. So even on Ethereum, if there were only one validator that created an incorrect block, all full nodes (including RPCs) would notice it and reject it. Wallets, explorers, etc. would halt and another honest validator would probably spin up.

This would mean that 51% attacks are not possible on a POS.

Even a validator with a 51% stake cannot propagate invalid blocks in the network. If it does, it will fork away from the rest of the chain.

I think a better way to look at it is to classify different malicious behaviors and see where economic security can help

Before settlement on Ethereum

Validators refer to Starknet validators

1. Invalid state transitions

Definition: The validator can convince others that a transaction causes the state to move from S → S’ when in reality the state moves from S → S’'.
Role of economic security: None in my opinion. If the validator does this, all full nodes will catch it as mentioned above.

2. Liveness failures

Definition: The validator can choose to censor some important transactions or not produce blocks at all.
Role of economic security:

1. If the malicious party can get >33% stake, they can prevent the chain from finalising.
2. If the malicious party can get >66% stake, they can move the chain forward with only blocks/transactions they want to include.

In either case, you need to socially fork and slash the malicious party. The stake of the validator must be > the damage caused by (1) and (2).

3. Reorgs

Definition: A validator can revert an L2 finalized block in favor of a new one. This is a safety failure under network consistency as @ilia mentioned.
Role of economic security: Reverting a previously finalized block for a new one means that 1/3rd of the stake will be slashed. So 1/3rd of the stake must be > damage caused by a reorg.

After settlement on Ethereum

As @ilia mentioned, I am assuming you’re now a user you wants to interact with Starknet state but only via Ethereum (you don’t want to rely on the consensus of Starknet validators)

Validators refer to Ethereum validators

1. Invalid state transitions

Definition: The validators convince you that Starknet settled on state S but it was actually S’.
Role of economic security: None in my opinion. Same reason as above.

2. Liveness failures

Definition: Assuming Starknet has forced inclusion via L1, the validators can censor your Starknet transaction.
Role of economic security: Same as above but we are now talking about Ethereum stake.

3. Reorgs

Definition: A validator reverts a finalized Ethereum block that contained a Starknet settlement transaction.
Role of economic security: Same as above but we are now talking about Ethereum stake.

So how much economic security does Starknet need?

but my point is that we’re an L2 and we have to pay the exact same price in inflation as an L1 for liveness, then why are we an L2 to begin with

I think this question has less to do with whether Starknet is an L1 or an L2. Instead, it has more to do with how much financial activity is relying on the consensus of Starknet validators and how much doesn’t. If Argent cards, fast bridges, etc. are going to be processing a billion dollars worth of volume based on the consensus of Starknet validators, then Starknet must have enough economic security to protect against this.

I’m playing the devil’s advocate here, but I also don’t see any evidence showing that liveness failure impact the performance of the token.

I think that’s subjective. I believe Solana has had red candles in outages before. Also, liveness can also cause other issues (being unable to sell, oracle updates etc.). However, estimating the impact of liveness faults is an existing unsolved problem I believe. I think a part of the debate that “economic security is a meme” stems from this. Because hypothetically, if we can detect and solve every liveness fault in 2 hours and it’s impossible to cause a damage >$50mn in this much time, then $1bn worth of economic security doesn’t mean too much.

What’s the advantage of being an L2

The advantage is that Starknet can secure financial activity greater than the amount of $STRK staked as long as apps use Ethereum to interact with Starknet. For example, let’s say Starknet has $50mn staked by validators but a SN user has $1bn USDC on the chain. If this user sends $1bn USDC to a CEX and SN validators vote on it, the CEX will still wait for SN to settle on the L1 before accepting the transaction (because the cost of attack is much less than the possible damage). If SN was an L1 with $50mn of economic security, it would just be impossible to get Circle to mint $1bn worth of USDC in the first place.

Effect of settlement times

So with the view I mentioned above, I would reason that the lower the settlement times get, the more people rely on Ethereum validation. Liveness would still be an issue (as @ilia also mentioned) but the amount of damage you can cause would intuitively be less if less people are relying on Starknet validators (example, Argent cards only check Ethereum to see if a txn went through). And so we need less economic security.

Is it possible to reduce the latency between the soft and hard finality drastically, or is it a dream?

I believe there are multiple factors here

1. Cost of verification on L1
2. Traffic on L2
3. Proof generation speed

(2) and (3) are independent of the L1 and so I feel it is possible to reduce the latency. But with Stwo, as mentioned above, we will only get (3).

[matteo]

Thanks for breaking this down, it’s very clear!

I think your first point sounds reasonable to me, and I can agree that the most important thing is legitimacy (if we remove extreme conditions like nation state attacks or infinitely powerful adversaries). But if we agree with this point, we have to dismiss the utility of being an L2, as invalid state transitions can’t be enforced. And using the same thinking process, if someone tries to re-org too many blocks, he will surely be slashed by the social consensus, explorer, wallets etc. And this number of blocks should be just one if we’re using tendermint, as blocks have a single slot finality (which is way faster and cost efficient than waiting for the hard Ethereum finality).

[apoorvsadana]

But if we agree with this point, we have to dismiss the utility of being an L2, as invalid state transitions can’t be enforced.

I sort of agree to your point but it depends on how you define the utility of an L2. You can still access enormous amount of liquidity from the L1, use apps and be safe from the perspective of the L1. But yes, at the same time, if you rely on soft confirmations you would need extra security protecting that confirmation.

And this number of blocks should be just one if we’re using tendermint, as blocks have a single slot finality

I am not sure if it’s necessary for the reorg count to be limited to 1. I believe that a malicious party which

1. Has at least 1/3rd stake
2. Can successfully partition the network into two parts

Can keep the two partitions unaware of each other for multiple blocks. Eventually, the malicious party will be slashed and there will be a reorg but it could be > 1 block. However, @ilia might be able to comment better over here

[matteo]

@apoorvsadana

You can still access enormous amount of liquidity from the L1, use apps and be safe from the perspective of the L1.

I’m not sure I understand what the first point means, if it means bridge easily from L1 to L2, we can keep the trust-minimized bridge as is, and be an L1. For the second point, I’m not sure it’s correct, because the “truth” now is the L2 consensus - if someone wants to settle something else than the L2 consensus, they will get slashed as suggests @NatanSW’s comment:

@NatanSW

The consensus is the extra layer that makes sure that the same proofs were propagated on L2 and sent to L1.

In the end we might keep the settlement on Ethereum (and Bitcoin at some point) for the narrative, and the cost of proof settlement and DA is negligeable compared to the inflation for staking so we might as well keep it, but technically we’ll be an L1, as the social consensus happens on Starknet, and the STRK token has its legitimacy on the L2 .

[apoorvsadana]

I don’t think we will be an L1 as that would have different security properties. What makes Starknet an L2 is that it reorgs with Ethereum. Take for example

1. User A bridges $1bn USDC from Ethereum to Starknet
2. User A sends $1bn USDC to user B in exchange for equivalent STRK
3. Eth reorgs and the $1bn USDC was never received on Starknet
4. Starknet reorgs as well and both user A and B txs on Starknet are invalidated
5. No money is lost

In the case of an L1 with a trust minimized bridge

1. User A bridges $1bn USDC from Ethereum to alt L1
2. User A sends $1bn USDC to user B in exchange for equivalent tokens
3. Eth reorgs and the $1bn USDC was never received on the alt L1
4. alt L1 doesn’t care about reorging and continues normally
5. User B lost his tokens and his USDC isn’t backed by anything

The L2’s economic security has less role to play in this case though. However, if we take the reverse case of L2 → L1 bridging then it becomes more relevant. If you were an alt L1 and you bridged natively minted funds to Ethereum (SOL is bridged to Ethereum for example) and if Solana has less economic security, then it’s possible for malicious actors to reorg and depeg SOL on Ethereum. For an L2 with even low economic security, this isn’t possible. What’s settled on Ethereum is final.

[matteo]

Sorry for the late reply, and thanks a lot for taking this discussion further down the rabbithole

What you’re saying makes a lot of sense, especially the first part on the Ethereum to Starknet bridging. While it may be a matter of semantics, I think that describing this as an L1 with enshrined bridging might be more accurate than calling it an L2. Indeed, if the Solana community, as part of their social consensus, decided to reorganize in response to a reorganization affecting the Solana <> Ethereum bridge, they could theoretically do so without settling on Ethereum. This approach does place additional burden on the consensus mechanism, but it’s conceptually possible.

On the reverse case, I don’t see how it’s impactful for Starknet, there’s a single slot finality, reorgs are slashed by the social consensus. Moreover, I’m not sure that it’s correct to say that the Starknet state published on L1 is the legitimate one, as, again, the comment from Natan suggests that the consensus will slash people settling another proof than the one given by Starknet’s consensus, and thus we could have an “invalid” state on L1, because the legitimacy comes from Starknet finality, and not what’s settled on Ethereum.

[apoorvsadana]

Thanks for this reply, so here’s what I think

Indeed, if the Solana community, as part of their social consensus, decided to reorganize in response to a reorganization affecting the Solana <> Ethereum bridge, they could theoretically do so without settling on Ethereum.

I think at this point Solana would become an L2. I actually think this thread by Ryan Berckmans is pretty insightful on this topic.

consensus will slash people settling another proof than the one given by Starknet’s consensus, and thus we could have an “invalid” state on L1, because the legitimacy comes from Starknet finality, and not what’s settled on Ethereum

I am on a different page here. I believe even in decentralised Starknet the L1 will be the final source of truth. I think what Natan meant when he said “slashed” is that L2 validators are disincentivised to settle a different state than the one the finalised on L2 consensus as they will lose money. And if we’ve enough economic security the slashed funds will cover for the loss. However, what’s settled on the L1 will remain settled.

Another point, when you say “invalid” state, I assume you mean state which is technically correct but different from the one communicated on the L2. Because technically the L1 verifier still checks for validity.

[matteo]

@apoorvsadana

I think at this point Solana would become an L2. I actually think this thread by Ryan Berckmans is pretty insightful on this topic.

Thanks for this resource, it’s very insightful. Anatoly’s comments are also interesting to rethink my mental model. What I understand from this, is, if we take Solana, build validity proofs and dump the blocks in blobs, we would expect that if the Solana consensus diverge from what’s settled on Ethereum, Solana’s consensus is the canonical state. If we go in the opposite direction, and Starknet, a with a centralized sequencer, starts to decentralize the sequencer. Same thing happens: Starknet’s consensus is different from what is settled on L1, then what’s settled on L1 should be the canonical state. In both cases, that’s what we assume will be the behaviour, because of the path taken by the protocols, but the outcome is determined by the social layer. Also, since Starknet bootstrapped its TVL of non-native assets through a native bridge, and not a third-party bridge, it’s harder to see how it could become an L1.

Thanks a lot for the discussion and educating me @apoorvsadana!

[Nadai2010]

In representation of the SEEDGov delegation, we support this proposal and consider this proposal to be a huge step forward for the Starknet ecosystem. We deeply believe that supporting the staking system is essential and that a Comittee to guarantee certain flexibility and adaptability is the right choice. Moreso, we value the new utility that this system will bring to the STRK token and the associated oportunities.

Nonetheless, we have some questions that we’d like to know

• Who will form the committee?
• How the selection process will be?
• What will be the workflow for presenting proposals?
• What will be the decision taking mechanism?

To our eyes, the technical debate needs to be complemented with the corresponding governance processes that make up to the full proposal. Lastly, with the implementation of Snapshot X we expect debates to become more active, decentralized and detailed