The idea is make it more dynamic, in terms of filters, Alive time, fee, missed slots(on v2) but trying to keep it simple, and maximizing the impact of every delegation on distribution, while only providing opportunities to stable and safe validators.
The only actual filter on top of range by delegated if is its verified or not(VoayagerVerified) and this already changes the composition of the 20% a lot.
If somehow the initiative managed to get some traction, if you distribute bottom 25% to 5% the composition of this set will be constantly changing so that will give opportunities to many people and do the most for decentralization, so far it only returns you one random validator per stake request, but another feature im planing is that you can choose to delegate to multiple validators in one tx.
Im also thinking of some kind of reward mechanism (maybe on starks, maybe own token) for the users that stake on random delegators(score based on impact) to help the app get more retention, and usage.
[quote=āNoeljarillo, post:16, topic:115250ā]I heard from a group member working on developing a dApp aimed at improving staking decentralization and supporting solo stakers.
The goal is to highlight the centralization of delegated STRK and create opportunities for smaller stakers to receive delegations.
ā¢ One feature provides metrics on the distribution of staked and delegated STRK across validators.
ā¢ Another allows users to stake with a randomly selected validator from the 20 with the least delegated STRK, giving smaller validators a fairer chance.]
SNIP 28 amendments: Attestation mechanism and commission increase feature
Following further refinements and community feedback, modifications to the Staking v2 proposal have been made. Both the validator attestation mechanism and the commission increase feature were changed. In the updated proposal, the attestation duty is based on block numbers, as outlined below. And the commission increase feature is simplified, without support for future commitments.
Revised Attestation Mechanism
Each Validator is assigned a block per epoch based on the following formula:
When the block_number is the relative number within the epoch, and W represents the range of blocks applicable for attestation submittal.
During each epoch, Validators have the opportunity to attest to their assigned block by submitting an attest transaction. This transaction includes the block hash of the attested block and must be included within a specific attestation window.
This change is beneficial because of the following:
Reduced Complexity: By removing N, fewer parameters need to be manually selected while maintaining fairness in validator selection. This also makes the attestation task more predictable for Validators.
Ensuring Inclusivity: Unlike the previous approach, where some Validators could, by chance, be left without an attestation opportunity in an epoch, this method ensures that all Validators have an attestation task each epoch.
Enabling flexible tuning: If required, the number of attestation opportunities per epoch can be adjusted without significant changes to the protocol structure.
Revised Commission increase feature
In the amended propsal, the commission increase feature is simplified by removing the ability for validators to declare future commission and eliminating the feature delay upon release. The key reason for this change is to focus on a minimally viable version (MVP) that ensures transparency while avoiding unnecessary complexity. Future extensions, such as commitment extensions or future commitment support, will be considered based on community demand and actual usage.
Staking V2 is a crucial step toward Starknetās decentralization, focusing on validator reliability and economic incentives. The introduction of block attestation ensures validators are actively engaged, while the ability to increase commission balances sustainability. These changes lay the groundwork for a more resilient and self-sustaining network ahead of the 2025 decentralization milestone.
The following reflects the views of L2BEATās governance team, composed of @krst, @Sinkas, and @Manugotsuka, and itās based on their combined research, fact-checking, and ideation.
Weāre voting FOR the proposal.
The introduction of a periodic liveness check to ensure validators are actively tracking the network before being eligible for receiving rewards is a good step to ensure weāre not spending money incentivizing validators who do not fully track activity.
The outlined specifications are sensible, and we do not see any points of concern that would urge us to consider voting against them. We look forward to the proposalās implementation and its impact on validatorsā liveness.