SNIP 18: Staking’s First Stage on Starknet

📜 Development Proposals SNIPs
41

Hey @_dd !
For you first question, the answer is yes but, they will be able to move to another Staker S’ without waiting the 21 days if they wish.
On LST, several teams are already working on such protocols, it would be on top of the basic Staking protocol we develop, not built by us.

42

Thanks @NatanSW. Are you expecting solo stakers? I know for consensus, sequencers will need to compute a zkp for a previous block in order to propose a block. Is this feasible for users with consumer hardware?

43

Hi @NatanSW , I have just read the SNIP and as others have said, it’s a good step for the decentralisation of starknet. Congratulations!
I have a few questions.

  • Based on your answer, in future the staked STRK will be granted voting powers. What will happen to the delegated STRK? Will the votes be delegated as well?
  • Will there be a limit to the number of STRK that can be staked per node? And for delegation? For example, is it possible to have a node with only 20k staked and millions/billions of STRK delegated?
  • About the R parameter: how do I decide what value to set if I don’t know the hardware specs? How do I know what is the minimum value I need to set to cover my costs?

I am concerned about the decentralisation and protocol security.

  • I believe the 20k minimum is to allow solo stakers, but can they do it? Proving zk stuff is very expensive. If it is not possible, the chain will probably have very few nodes.
  • I am worried about delegations in the early stages especially if they give voting rights. Bad actors may start a race to drive R down to unsustainable values (the worst being R = 1 or 0) to get the maximum delegations and voting power. Moreover, in the early phases, when the costs are lower (or even 0 for bad actors), bad actors may vote against to some proposals or they try to harm the chain (stealing rewards harms the protocol). Honest players who get caught to the race will have to create a new node losing all their delegations.
  • About the R: is it possible to replace R with two parameters? The first, called maximum reward, is the same as R (and can only be lowered). The second is the actual fee can vary [0, maxFee] and it is used to calculate the commissions. The solution may solve the problem above. It should be easy to implement.
44

Only the pledged address can have voting rights, right?

45

Hay cosas que no están definidas o que si lo están aun no se han explicado.

  • me preocupa la centralización o la falta de proporcionalidad entre los validadores, es decir es bueno establecer por ejemplo que cada nodo o validador no pueda contener más del 5% del total en stake.
  • tampoco señala que no exista umbral en el poder de voto/stake es decir un VC que posea 1b no puede solo decidir que hacer con la red.
  • si bien se establece que mientras más STRK en stake menor será el STRK qué se distribuirá, el problema es que en unos inicios los VC. Estarán incentivandos a sostener sus token, en una fase intermedia dicha política incentivara a que ellos los vuelquen a mercado.
  • si bien eth hoy es deflacionaria, sus inicios fueron con inflación, la pregunta es si existirá algún mecanismo para que STRK sea deflacionaria?
46

Hey @NMoustache !
Thanks for taking the time to review and ask good questions :pray:

  • Not yet final: Staked delegated will also be counted as voting power for themselves. They could later delegate that voting power to anyone.
  • We found setting an upper bound not effective. The reason being you cannot know what is actually run per address. You can easily have multiple addresses using only a single instance of a sequencer. It does not ensure robustness or Stake distribution, unfortunaltly.
  • Currently no. We had a feature that sets a hard limit on the ratio between self_stake and delegated_stake. We decided not to implement it as it was too harsh and did not result in a better Stake distribution. You can check the first amendment to this SNIP linked above for more details. We will think of ways to have a more sophisticated way to incentivise self-stake.
  • About setting R, it depend on the amount of delegations you have and the market conditions. You can always lower it, and in the future, we might have more sophisticated commission policies like for example change within a time delay. The cost you should take into account right now is of running a full node. You can find our full node implementations and spec here:
  1. Juno (GitHub - NethermindEth/juno: Starknet client implementation.) by Nethermind - Spec (Hardware Requirements | Juno).
  2. Pathfinder (GitHub - eqlabs/pathfinder: A Starknet full node written in Rust) by EQLabs - Spec (Example: Pathfinder Node - The Starknet Book).
  • Utilizing STWO would make “zk stuff” much more accessible and cheap, it is a total game changer.
  • So having Stake delegations would not mean having a lot of voting power, exactly for that reason! see the first bullet point.
  • This is a very interesting suggestion! For this version, no. For later versions, this is totally on the table with other suggestions, thanks!