Staking on Starknet voting proposal

Yes, I think we’re on the same page now! Thanks for constructive feedback :slight_smile:

Just posting my message on Telegram here

“I tend to agree with @BGLabs that the rewards are too high as it stands”

First, let me clarify this point, as it’s not really what I think. I have no strong opinion on the staking rewards, I guess that you have to set it somewhere above 4% ( which is the best risk free yield in crypto with Ethereum + the US risk free yields) and under 15% (arbitrary). But my initial point was on the fact that we’ll be paying similar amounts in inflation to stakers to L1s, which was very disturbing to me. I stand corrected by @apoorvsadana & @iliav on the forum, as blockchains offer a spectrum of propreties that can’t be guaranteed by validity proofs (which only provide trustlessness), and especially liveness and consistency (which you just discussed above). In the end, we might have to pay this high level of inflation (btw inflation here can be deflation if the marginal price of including a transaction is inferior to the fee users are willing to pay)

Now let me open the discussion to a few additional points that are, to me, worth discussing for our future.

I understand that we want to be the first to decentralize the sequencer for many reasons: ideological, security, image etc. But I think that we overlooked a ton of aspects and problems that are going to come with the decentralization.

  1. First one is MEV, what’s the roadmap here, how do we plan to protect the honest user? A centralized FIFO may not be the best solution, but there’s dynamics here that are going to change, depending on the stake of validators. The fact that the blocktime is huge (30s is still a lot) is going to create a long monopole for the leader.
  2. Second, is around scalability and UX. We all pretty much agreed to use Tendermint for Starknet, but are we going to see the UX and TPS affected? As I understand BlockSTM will still be in prod, but do we have any benchmarks? What about latency? By agreeing to Tendermint (and any other consensus mechanism btw), we’re taking the decision that scaling the L2 is now the same job as scaling the L1, which means hard distributed systems work, and direct competition with other L1s on this subject for latency and TPS. Are we the best armed to fight on Solana, Sui, Aptos’ field?
  3. I’m asking questions without providing any answer, and again Apoorv and Ilia educated me on the forum on why it’s necessary to take this decision. But one of the core benefits of Starknet as an L2 is the centralized sequencer, which can be scaled to god know how many TPS. Whenever we introduce a traditional L1 consensus, we introduce new bottlenecks to scaling with bandwidth, message rounds etc. Isn’t there a way to preserve this sequencer “centralization” (maybe with some rotation, but without having to come to consensus which is the hard thing) without sacrifizing trustlessness, liveness, CR, consistency? I think this is a direction worth exploring, and that could potentially give us an unfair advantage over other L1s and L2s

Hi folks! I’m seeking some clarity on the minting cap formula being used. Specifically: is the formula M = C/10 * √ S or M = C * √ S ?

While most, but not all, resources reference M = C/10 * √ S - including the approved vote - the Appendix on this post is the only place I’ve found that implements the formula using some examples. If my math checks out, this Appendix is actually using M = C * √ S.

Example: 1.4% total supply staked, C = 1.6%. Using M = C/10 * √ S

  • M = 0.016/10 * √0.014
  • M = 0.00019 => 0.019% Minting Rate, not the 0.19% shown above.

Using M = C * √ S moves the decimal a spot => 0.19% Minting Rate.

Appreciate any feedback and insights, thank you!

Looking at the code - it seems to confirm my suspicion that the example values provided in the OP’s table don’t line up with a minting curve formula of M = C/10 * √ S

@BoazStark wdyt, does that line up?

Answering both comment here @mike-u410 .
We talked and checked together, the missing thing from your calculation was the value of C. you used it not a as a percentage. Thanks for checking and double checking us!