SNIP 28: Staking V2 proposal

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:

block_number=Hash(staked_amount,epoch_id,validator_address)%(Eβˆ’W)

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.