RFC: Feature Threshold Mechanism: Accounts or Blocks #424
Replies: 4 comments 17 replies
-
|
Thanks for writting this up @buffalojoec! I think I am personally leaning towards block footer signalling for a few reasons:
Complexity wise the bitmask one would probably be more complicated to implement than on chain voting. We also potentially need to account for cases where you might have 2 feature gates due to be activated and you only support one of them, with account based voting its straight forward, but here we need to encode that into the bitmask and keep that in mind for the runtime. Re observability account based voting is simpler for sure, with block signaling we can either calculate it off-chain as you suggested or expose metrics from the validators somehow, will require an engineering effort here. Concerns:
|
Beta Was this translation helpful? Give feedback.
-
|
A few questions with the block footer route:
|
Beta Was this translation helpful? Give feedback.
-
|
I lean towards the transaction sending on-chain account based approach. Stake support information is primarily needed for on-chain logic: feature activations. Therefore it should live in the same place as the other on-chain state: in an account. This has other advantages:
Relying on off-chain protocols for this information is fragile. We already have a mechanism for synchronising state needed by the runtime - the on-chain accounts - which each client must keep synchronised correctly. That's the perfect place to store this information. AFAICT, the main downside of this approach is that each validator has to send a transaction every epoch. Are we concerned about the cost? Or the transaction sending mechanism? I would think the cost of a single transaction every epoch is negligible compared to the overhead of operating a validator. |
Beta Was this translation helpful? Give feedback.
-
|
The downside I see with tx signaling is that the identity account is required to sign the tx. With the Alpenglow rollout, I believe the desire is to have the VAT be charged in the vote account. Once that's in place, the protocol could put rewards from tx fees and priority fees in the vote account as well. Then the validator operator wouldn't need to have access to a key with funds. At least that's my understanding. @wen-coding for confirmation. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
Feature Threshold Mechanism: Accounts or Blocks
The network requires a more robust solution for activating features. Currently,
contributors can submit feature activations with a single keypair, often
ignoring the network's stake distribution across compatible client versions.
Since features are forking events, this is a critical infrastructure risk as
well as a centralization vector. Validators should be able to collectively
activate or block feature activations through quorum.
SIMD-0072 proposed an enshrined on-chain protocol that would solve this
problem. In short, the protocol would require validator approval for any staged
feature activations to become live. However, an equally compelling alternative
design has been proposed, leading to SIMD-0072's long stalemate.
This RFC presents both designs and their tradeoffs to reach a decision on which
to implement.
SIMD-0072: Account-Based Signaling
SIMD-0072 introduces an on-chain protocol where validators explicitly signal
support for staged features via transactions. The Feature Gate program tallies
stake-weighted support, and the runtime activates staged features that meet the
threshold at epoch boundaries.
The process works as follows:
features they support.
support.
Feature accounts use a new
FeatureV2state that tracks status, stagingauthority, and accumulated stake support:
Validators signal support by submitting a
SignalSupportForStagedFeaturestransaction that includes all feature accounts they wish to support. The
instruction requires the validator's authorized voter as a signer and their
vote account as a reference.
A signal account PDA prevents double-signaling within an epoch:
The Feature Gate program uses the
SolGetEpochStakesyscall to retrieve eachsignaling validator's stake weight and accumulates it in the
stake_supportfield of each included feature account.
Features must be explicitly staged before they can be activated; the signaling
mechanism only determines whether a staged feature has sufficient support to go
live. At the epoch boundary, the runtime compares each staged feature's
accumulated support against total cluster stake and activates those meeting the
threshold.
Pros
during the epoch.
special tooling.
Cons
(misconfiguration, downtime, neglect) effectively votes against all staged
features.
transaction incurs fees.
Alternative: Block Footer Signaling
Block footer signaling embeds feature support directly in block production.
Rather than submitting explicit transactions, leaders include a bitmask in the
block footer indicating which features their client supports. The runtime
maintains a running tally of stake-weighted support and activates staged
features at epoch boundaries.
SIMD-0307 introduced block footers as mandatory structured data appended to
each block. Feature signaling would extend the footer with a bitmask field:
The bitmask encodes support for features in the current major version's feature
set. The exact encoding is a design detail to be determined, but one possibility
is to assign bit positions based on source order in the feature-set crate, with
universally activated features pruned on each major release to keep the bitmask
compact.
As with SIMD-0072, features must still be staged before they can be activated.
The signaling mechanism only determines whether a staged feature has sufficient
support to go live.
Unlike SIMD-0072, stake support is accumulated in the runtime rather than
on-chain. As each block is processed, the runtime accumulates the leader's stake
toward each supported feature. At the epoch boundary, the runtime compares
accumulated support against total cluster stake and activates staged features
meeting the threshold.
Pros
transaction or operational step required.
production.
Cons
though leader selection should cover most stake over a full epoch.
support levels requires RPC extensions or reconstructing tallies from block
data.
Call to Action
This RFC requests explicit review from the following core contributors:
Any additional community members are welcome to provide feedback and their input
will be equally considered. The above merely lists contributors already involved
in this debate or with relevant domain expertise.
Reviewers should weigh in on which design they prefer, considering factors such
as:
Beta Was this translation helpful? Give feedback.
All reactions