Mainnet uses inflating tail emission #6122
Assignees
Labels
A-base_node
Area - The Tari base node executable and libraries
C-enhancement
Category - New feature or request
C-proposal
Before becoming formal RFCs, new ideas are written up as proposals and discussed in the community
Comments
CjS77
added
C-enhancement
|
Being implemented in tari core with feature flag |
Closed
CjS77
added a commit
that referenced
this issue
Feb 8, 2024
This PR primarily adds tail emission inflation as a featuer; but it does so using feature gates, which were broken in a few places, and so a big part of this PR is resolving issues related to feature gates. == Tail emission inflation Adds a feature tari_feature_mainnet_emission to allow for tail emission inflation. See #6122 This change necessitates the addition of 2 new consensus constants: `inflation_bips` -- the annual inflation rate of the total supply. and `tail_emission_epoch_length`, which controls the tail emission inflation. These replace `tail_emission`. We update the Protobuf definition for ConsensusConstants to account for the new fields. == Getting Feature flags working When formally implementing compiler features, the setting of the `TARI_NETWORK` and (from now) `TARI_TARGET_NETWORK` envar and the related compiler flags matter. These changes require that when tests run, the correct network flags are set. For example, blocks::genesis_block::test::stagenet_genesis_sanity_check should only run when TARI_NETWORK=stagenet. While writing this PR, I uncovered a problem: There is not a 1:1 mapping between the build _target_ and the actual network the binary may run on. E.g. the mainnet build can run on either stagenet or mainnet. Unfortunately the `TARI_NETWORK` envar was used to set both of these variables. Without using feature flags, this discrepency went unnoticed. With feature flags, a lot of tests that implicitly assumed say a mainnet target and a stagenet run would simply fail, with no way to resolve the issue. Since these are 2 different things, this commit introduced `TARI_TARGET_NETWORK` whicg sets the **build target**. In most contexts, this then decouples the configured network, which is specified by the `TARI_NETWORK` envar as usual. The other changes in this commit revolve around updating merkle roots and the correct faucet sets to make the target/network/faucet combination consistent. == CI workflows The CI is configured to run tests for each of * Testnet (Esme) * Nextnet (Nextnet) * Mainnet (Mainnet, with some tests specifying stagenet)
CjS77
added a commit
that referenced
this issue
Feb 8, 2024
This PR primarily adds tail emission inflation as a featuer; but it does so using feature gates, which were broken in a few places, and so a big part of this PR is resolving issues related to feature gates. == Tail emission inflation Adds a feature tari_feature_mainnet_emission to allow for tail emission inflation. See #6122 This change necessitates the addition of 2 new consensus constants: `inflation_bips` -- the annual inflation rate of the total supply. and `tail_emission_epoch_length`, which controls the tail emission inflation. These replace `tail_emission`. We update the Protobuf definition for ConsensusConstants to account for the new fields. == Getting Feature flags working When formally implementing compiler features, the setting of the `TARI_NETWORK` and (from now) `TARI_TARGET_NETWORK` envar and the related compiler flags matter. These changes require that when tests run, the correct network flags are set. For example, blocks::genesis_block::test::stagenet_genesis_sanity_check should only run when TARI_NETWORK=stagenet. While writing this PR, I uncovered a problem: There is not a 1:1 mapping between the build _target_ and the actual network the binary may run on. E.g. the mainnet build can run on either stagenet or mainnet. Unfortunately the `TARI_NETWORK` envar was used to set both of these variables. Without using feature flags, this discrepency went unnoticed. With feature flags, a lot of tests that implicitly assumed say a mainnet target and a stagenet run would simply fail, with no way to resolve the issue. Since these are 2 different things, this commit introduced `TARI_TARGET_NETWORK` whicg sets the **build target**. In most contexts, this then decouples the configured network, which is specified by the `TARI_NETWORK` envar as usual. The other changes in this commit revolve around updating merkle roots and the correct faucet sets to make the target/network/faucet combination consistent. == CI workflows The CI is configured to run tests for each of * Testnet (Esme) * Nextnet (Nextnet) * Mainnet (Mainnet, with some tests specifying stagenet)
CjS77
added a commit
that referenced
this issue
Feb 9, 2024
This PR primarily adds tail emission inflation as a featuer; but it does so using feature gates, which were broken in a few places, and so a big part of this PR is resolving issues related to feature gates. == Tail emission inflation Adds a feature tari_feature_mainnet_emission to allow for tail emission inflation. See #6122 This change necessitates the addition of 2 new consensus constants: `inflation_bips` -- the annual inflation rate of the total supply. and `tail_emission_epoch_length`, which controls the tail emission inflation. These replace `tail_emission`. We update the Protobuf definition for ConsensusConstants to account for the new fields. == Getting Feature flags working When formally implementing compiler features, the setting of the `TARI_NETWORK` and (from now) `TARI_TARGET_NETWORK` envar and the related compiler flags matter. These changes require that when tests run, the correct network flags are set. For example, blocks::genesis_block::test::stagenet_genesis_sanity_check should only run when TARI_NETWORK=stagenet. While writing this PR, I uncovered a problem: There is not a 1:1 mapping between the build _target_ and the actual network the binary may run on. E.g. the mainnet build can run on either stagenet or mainnet. Unfortunately the `TARI_NETWORK` envar was used to set both of these variables. Without using feature flags, this discrepency went unnoticed. With feature flags, a lot of tests that implicitly assumed say a mainnet target and a stagenet run would simply fail, with no way to resolve the issue. Since these are 2 different things, this commit introduced `TARI_TARGET_NETWORK` whicg sets the **build target**. In most contexts, this then decouples the configured network, which is specified by the `TARI_NETWORK` envar as usual. The other changes in this commit revolve around updating merkle roots and the correct faucet sets to make the target/network/faucet combination consistent. == CI workflows The CI is configured to run tests for each of * Testnet (Esme) * Nextnet (Nextnet) * Mainnet (Mainnet, with some tests specifying stagenet) === remove env_logger I used env_logger to try print the feature list at compiler time, but it doesn't work, so rather remove it. A better strategy (implemented in this commit) is to print "tari_feature" as a prefix to the message emitted by build.rs. Then you can do soemthing like `cargo build -vv .... 2>/dev/null` | grep "tari_feature"` Piping stderr to dev null hides all the noise from rustc, and then you can grep for the messages you want (or omit the grep to see the usual build messages among the rest) === set network according to pols Sets the network according to the principle of least surprise. i.e. if TARI_NETWORK is set, try and make that the default network.
CjS77
added a commit
that referenced
this issue
Feb 21, 2024
Adds a feature `tari_feature_mainnet_emission` to allow for tail emission inflation. See #6122 This change necessitates the addition of 2 new consensus constants: `inflation_bips` -- the annual inflation rate of the total supply in basis points (100 bips = 1 percentage point). and `tail_emission_epoch_length`, which controls the tail emission inflation. These replace `tail_emission`. We update the Protobuf definition for `ConsensusConstants` to account for the new fields. Updates tests Adds `as_u128` to `MicroMinotari` since we need to perform a large multiplication when calculating the inflation issuance. Note: Replaces part of #6131
SWvheerden
pushed a commit
that referenced
this issue
Feb 28, 2024
## Summary Adds a feature `tari_feature_mainnet_emission` to allow for tail emission inflation. See #6122 This change necessitates the addition of 2 new consensus constants: `inflation_bips` -- the annual inflation rate of the total supply. and `tail_emission_epoch_length`, which controls the tail emission inflation. These replace `tail_emission`. We update the Protobuf definition for `ConsensusConstants` to account for the new fields. Note: Replaces part of #6131
|
this is done |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
and others
The Minotari emission schedule
The Minotari emission schedule was designed to achieve multiple goals:
Coins that have a fixed supply with no tail emission, such as Bitcoin, are strictly deflationary.
On the other hand, Monero has a constant tail emission. Its total supply is technically infinite, but its emission is disinflationary, since the annual inflation rate of the Monero supply is continuously approaching zero. The tail emission is broadly in place to account for coins that are lost due to the fact that people are involved in the system, and people tend to lose and/or break things.
Bitcoin and Monero have one job: To be money.
But Minotari has a very important second role: to be converted into the Tari tokens that fuel the Tari Digital Assets Network.
The word fuel is not just metaphorical. A small portion of the transaction fee in every single one of Tari’s second layer instructions is burnt. This creates a small but constant driving force to convert Minotari into Tari. This simple and elegant design is called the turbine model. It maintains a soft 1:1 peg between Tari and Minotari without having to resort to complicated peg-out mechanisms like drive chains, or federated pegs like Liquid. In fact, there’s no peg-out at all. This offers the tremendous benefit of allowing the Tari network to operate at its native speed (fast!).
Because of the turbine model, in the absence of a tail emission, we would eventually run out of Tari. But even a disinflationary token may experience liquidity problems in the long run if the second layer experiences sustained growth.
Imagine if the Tari tail emission was a constant 800 XTR per block. If the Tari network was burning more than that every two minutes due to sustained high activity, then the supply of Tari globally would fall.
Therefore, Tari’s tail emission is mildly inflationary in nominal terms. Real GDP growth typically sits somewhere between 1% and 3% per annum. The genesis block has encoded parameters that initiate a tail emission inflation rate at the low end of this range.
The tail emission kicks in as soon as the annual inflation rate of Minotari drops below the target rate and is set to provide a 1% supply increase over the course of the next 12 months. Every 12 months, the block reward is boosted to maintain the 1% supply growth going forward.
So once the tail emission is active, Tari will undergo boostings as opposed to Bitcoin’s halvings.
Given a target rate of 1%, the tail emission will commence in the 13th year of Tari’s existence and each boosting will increase the reward slightly to maintain the inflation rate at a shade under 1%. The first ten boostings are listed in Table 1.
The text was updated successfully, but these errors were encountered: