Feature Proposal Program
The Feature Proposal Program provides a workflow for activation of PUT network features through community vote based on validator stake weight.
Community voting is accomplished using PPL Tokens.
Tokens are minted that represent the total active stake on the network, and distributed to all validators based on their stake.
Validators vote for feature activation by transferring their vote tokens to a predetermined address. Once the vote threshold is met the feature is activated.
Background
The PUT validator software supports runtime feature activation through the built-in Feature program.
This program ensures that features are activated simultaneously across all validators to avoid divergent behavior that would cause hard forks or otherwise break consensus.
The feature and feature_set Rust modules are the primitives for this facility, and the PUT feature command-line subcommands allow for easy feature status inspection and feature activation.
The PUT feature activate workflow was designed for use by the core PUT developers to allow for low-overhead addition of non-controversial network features over time.
The Feature Proposal Program provides an additional mechanism over these runtime feature activation primitives to permit feature activation by community vote when appropriate.
Source
The Feature Proposal Program's source is available on github
Interface
The Feature Proposal Program is written in Rust and available on crates.io and docs.rs.
Command-line Utility
The spl-feature-proposal command-line utility can be used to manage feature proposal.
Once you have Rust installed, run:
Run spl-feature-proposal --help for a full description of available commands.
Configuration
The spl-feature-proposal configuration is shared with the PUT command-line tool.
Feature Proposal Life Cycle
This section describes the life cycle of a feature proposal.
Implement the Feature
The first step is to conceive of the new feature and realize it in the PUT code base, working with the core PUT developers at https://github.com/put-labs/put.
During the implementation, a feature id will be required to identity the new feature in the code base to avoid the new functionality until its activation.
The feature id for a feature proposal is derived by running the following commands.
First create a keypair for the proposal:
Now run the spl-feature-proposal program to derive the feature id:
which in this case is HQ3baDfNU7WKCyWvtMYZmi51YPs7vhSiLn1ESYp3jhiA.
HQ3baDfNU7WKCyWvtMYZmi51YPs7vhSiLn1ESYp3jhiA is the identifier that will be used in the code base and eventually will be visible in the PUT feature status command.
Note however that it is not possible to use PUT feature activate to activate this feature, as there is no private key for HQ3baDfNU7WKCyWvtMYZmi51YPs7vhSiLn1ESYp3jhiA.
Activation of this feature is only possible by the Feature Proposal Program.
Initiate the Feature Proposal
After the feature is implemented and deployed to the PUT cluster, the feature id will be visible in PUT feature status and the feature proposer may initiate the community proposal process.
This is done by running:
If the output looks good run the command again with the --confirm flag to continue, and then follow the remaining steps in the output to distribute the vote tokens to all the validators.
COST: As a part of token distribution, the feature proposer will be financing the creation of PPL Token accounts for each of the validators.
A PPL Token account requires 0.00203928 PUT at creation, so the cost for initiating a feature proposal on a network with 500 validators is approximately 1 PUT.
Tally the Votes
After advertising to the validators that a feature proposal is pending their acceptance, the votes are tallied by running:
Anybody may tally the vote. Once the required number of votes are tallied, the feature will be automatically activated at the start of the next epoch.
Upon a successful activation the feature will now show as activated by PUT feature status as well.
Last updated