Feature gating

[brianp]

Problem

Once mainnet is live we want to ensure the safe development and testing of features occur on the appropriate networks, and that we prevent the use of these features on the wrong network.

Solution 1

Define features

In build.rs, we define our features.

Features have a

• name - will also be the attribute name you use in code
• description - a short description of the features
• issue tracking number on github
• The current status.

Status

• New: New feature, may not even be working or compiling. Will be present on dibbler testnet
• Testing: Potentially active feature, but still gated. Potentially present on nextnet,
• Active: Feature is live and gate has been removed. Will be running on stagenet and mainnet
• Removed: Feature has been cancelled. Can not be invoked anywhere

In build.rs, we maintain the list of feature flags. For example:

const FEATURE_LIST: [Feature; 4] = [
    Feature::new("add_pair", "Allows you to add two numbers together", Some(123), Status::New),
    Feature::new("about_to_launch", "Live in NextNet. If we stabilise, will go to mainnet", Some(123), Status::Testing),
    Feature::new("live_feature", "This feature has been stabilised and is live!", Some(150), Status::Active),
    Feature::new("old_feature", "We decided not to go with this featuree", Some(145), Status::Removed),
];

Demarcate feature flag code

In your code, you can now use any of the flags as attributes to mark code belonging to a feature.

Example

#[tari_feature(add_pair)]
use add_pair::add_pair;

fn main() {
    println!("Hello world!");
    #[tari_feature(add_pair)]
    println!("40 + 2 = {}", add_pair(40, 2));
    println!("foo={}", foo());
    println!("Bye, world!");
}

#[tari_feature(add_pair)]
fn foo() -> usize {
    1
}

#[tari_feature(!add_pair)]
fn foo() -> usize {
    2
}

Specify the target network when building

This PoC uses the TARI_NETWORK envar to specify the target network, but in principle, we can also read the Cargo.toml
file, or compiler flags.

$ TARI_NETWORK=dibbler cargo run -vv

Filtered output:

Building for Dibbler
These features are ACTIVE on mainnet (no special code handling is done)
live_feature. This feature has been stabilised and is live!. Tracking issue: https://github.com/tari-project/tari/issues/150

These features are DEPRECATED and will never be compiled
old_feature. We decided not to go with this featuree. Tracking issue: https://github.com/tari-project/tari/issues/145

** Activating add_pair. Allows you to add two numbers together. Tracking issue: https://github.com/tari-project/tari/issues/123 **
** Activating about_to_launch. Live in NextNet. If we stabilise, will go to mainnet. Tracking issue: https://github.com/tari-project/tari/issues/123 **

Finished dev [unoptimized + debuginfo] target(s) in 7.44s
     Running `target/debug/feature_gates`
Hello world!
40 + 2 = 42
foo=1
Bye, world!

Or compiling for MainNet:

$ TARI_NETWORK=mainnet cargo run -vv

Filtered output:

Building for MainNet

These features are ACTIVE on mainnet (no special code handling is done)
live_feature. This feature has been stabilised and is live!. Tracking issue: https://github.com/tari-project/tari/issues/150

These features are DEPRECATED and will never be compiled
old_feature. We decided not to go with this featuree. Tracking issue: https://github.com/tari-project/tari/issues/145
    Finished dev [unoptimized + debuginfo] target(s) in 6.15s
     Running `target/debug/feature_gates`
Hello world!
foo=2
Bye, world!

Solution 2

Define features, and demarcate code the same as Solution 1.
Perform feature authorization checks at runtime based on the network in use.

Rabbit Holes

All crates across the repo require the feature gating functionality and access to the current feature list.

No Gos

Gating the configuration settings of other networks. For example, a mainnet binary may still know about the settings for testnets.
...

[brianp]

I've been working on a PR for solution 1 as originally proposed but the more I look at it the more I dislike it.
It feels like we're creating a lot of extra work for ourselves in compilation management and distribution. Providing different bins for each application based on the network they would run on. Where currently we offer the ability to quickly switch the network based on config, or startup flags. Is the eventual plan to prevent the switching of networks and force the network based on the bin?
I can see this causing issues for us in other apps, like Aurora, and Launchpad. They have the ability to switch networks but their libraries would be compiled to a specific feature set.

Flag checking at runtime would introduce a minor performance hit but offer far more flexibility for all other applications.

[brianp]

Closed with #5287