diff --git a/docs/emissions.md b/docs/emissions.md index 508e00c93..90896fb76 100644 --- a/docs/emissions.md +++ b/docs/emissions.md @@ -18,32 +18,40 @@ See the [Dynamic TAO White Paper](https://drive.google.com/file/d/1vkuxOFPJyUyoY ### Injection -The first stage of emissions is *injection of liquidity* into the subnet pools. Liquidity is injected to each subnet in proportion to the price of its token compared to the price of other subnet tokens. This is designed to incentivize development on the most valuable subnets. +The first stage of emissions is _injection of liquidity_ into the subnet pools. Liquidity is injected to each subnet in proportion to the price of its token compared to the price of other subnet tokens. This is designed to incentivize development on the most valuable subnets. Each block: - TAO is injected into the subnet's **TAO reserve**. - Alpha is injected into the subnet's **alpha reserve**. -- Alpha is allocated to *alpha outstanding*, to be extracted by participants. +- Alpha is allocated to _alpha outstanding_, to be extracted by participants. #### TAO reserve injection A subnet's TAO reserve injection is computed in proportion to the price of its alpha token over the sum of prices for all the subnets in Bittensor. -Given set $\mathbb{S}$ of all subnets, and a total per block TAO emission $\Delta\bar{\tau}$, which begins at 1 TAO and follows a halving schedule, TAO emission $\Delta\tau_i$ to subnet $i$ with price $p_i$ is: +
+ See how it's calculated! -$$ -\Delta\tau_i = \Delta\bar{\tau} \times -\frac - {p_i} - {\sum_{j \in \mathbb{S}} -\bigl(p_j)} -$$ + Given set $\mathbb{S}$ of all subnets, and a total per block TAO emission $\Delta\bar{\tau}$, which begins at 1 TAO and follows a halving schedule, TAO emission $\Delta\tau_i$ to subnet $i$ with price $p_i$ is: + + $$ + \Delta\tau_i = \Delta\bar{\tau} \times + \frac + {p_i} + {\sum_{j \in \mathbb{S}} + \bigl(p_j)} + $$ + +
#### Alpha reserve injection Alpha is then injected in proportion to the price of the token, so that growth of a subnet's liquidity pools does not not change the price of the alpha token. +
+ See how it's calculated! + Recall that token price for a subnet is its TAO in reserve divided by its alpha reserve: $$ @@ -63,15 +71,14 @@ $$ When we fill in this equation with the previous formula for $\Delta\tau_i$, the price $p_i$ is cancelled out of the equation, yielding: $$ -\Delta\alpha_i = +\Delta\alpha_i = \frac {\Delta\bar{\tau}} {\sum_{j \in \mathbb{S}} \bigl(p_j)} $$ - -However, alpha injection is also capped at 1 by the algorithm, to prevent runaway inflation. Therefore, with cap or *alpha emission rate* $\Delta\bar{\alpha_i}$, emission $\Delta\alpha_i$ to subnet $i$ is: +However, alpha injection is also capped at 1 by the algorithm, to prevent runaway inflation. Therefore, with cap or _alpha emission rate_ $\Delta\bar{\alpha_i}$, emission $\Delta\alpha_i$ to subnet $i$ is: $$ \Delta\alpha_i = \min\left\{ @@ -80,14 +87,15 @@ $$ {\sum_{j \in \mathbb{S}} \bigl(p_j)}, \Delta\bar{\alpha_i} \right\} - $$ -The cap or *alpha emission rate* $\Delta\bar{\alpha_i}$ for subnet $i$, starts at 1 and follows a halving schedule identical to that of TAO, beginning when subnet $i$ is created. +The cap or _alpha emission rate_ $\Delta\bar{\alpha_i}$ for subnet $i$, starts at 1 and follows a halving schedule identical to that of TAO, beginning when subnet $i$ is created. + +
#### Alpha outstanding injection -Each block, liquidity is also set aside to be emitted to participants (validators, miners, stakers, and subnet creator). The quantity per block is equal to the *alpha emission rate* $\Delta\bar{\alpha_i}$ for subnet $i$. +Each block, liquidity is also set aside to be emitted to participants (validators, miners, stakers, and subnet creator). The quantity per block is equal to the _alpha emission rate_ $\Delta\bar{\alpha_i}$ for subnet $i$. ### Extraction @@ -96,30 +104,31 @@ At the end of each tempo (360 blocks), the quantity of alpha accumulated over ea 1. 18% by subnet owner 1. 41% of emissions go to miners. The allocation to particular miners is determined by [Yuma Consensus: Miner emissions#miner-emissions](./yuma-consensus). 1. 41% by validators and their stakers. - 1. First, the allocation to validators miners is determined by [Yuma Consensus: Validator Emissions](./yuma-consensus#validator-emissions). - 1. Then, validators extract their take from that allocation. - 1. Then, TAO and alpha are emitted to stakers in proportion to the validators' holdings in each token. TAO emissions are sourced by swapping a portion of alpha emissions to TAO through the subnet's liquidity pool. - For validator x's TAO stake $\tau_x$, and alpha stake $\alpha_x$, and the global TAO weight $w_{\tau}$: + 1. First, the allocation to validators miners is determined by [Yuma Consensus: Validator Emissions](./yuma-consensus#validator-emissions). + 1. Then, validators extract their take from that allocation. + 1. Then, TAO and alpha are emitted to stakers in proportion to the validators' holdings in each token. TAO emissions are sourced by swapping a portion of alpha emissions to TAO through the subnet's liquidity pool. + + For validator x's TAO stake $\tau_x$, and alpha stake $\alpha_x$, and the global TAO weight $w_{\tau}$: - - TAO is emitted to stakers on the root subnet (i.e. stakers in TAO) in proportion to the validator's stake weight's proportion of TAO. + - TAO is emitted to stakers on the root subnet (i.e. stakers in TAO) in proportion to the validator's stake weight's proportion of TAO. - $$ - \text{proportional emissions (\%) to root stakers} - = \frac{\tau_{x}{} \, w_{\tau}} - {\alpha_{x} + \tau_{x} \, w_{\tau}} - $$ + $$ + \text{proportional emissions (\%) to root stakers} + = \frac{\tau_{x}{} \, w_{\tau}} + {\alpha_{x} + \tau_{x} \, w_{\tau}} + $$ - - Alpha is emitted to stakers on the mining subnet (i.e. stakers in alpha) in proportion to the validator's stake weight's proportion of alpha: - $$ - \text{proportional emissions (\%) to alpha stakers} - = \frac{\alpha_{x}} - {\alpha_{x} + \tau_{x} \, w_{\tau}} - $$ + - Alpha is emitted to stakers on the mining subnet (i.e. stakers in alpha) in proportion to the validator's stake weight's proportion of alpha: + $$ + \text{proportional emissions (\%) to alpha stakers} + = \frac{\alpha_{x}} + {\alpha_{x} + \tau_{x} \, w_{\tau}} + $$ - Validators who hold both root TAO and subnet alphas will extract both types of token. + Validators who hold both root TAO and subnet alphas will extract both types of token. - See [Core Dynamic TAO Concepts: Validator stake weight](../subnets/understanding-subnets#validator-stake-weight) + See [Core Dynamic TAO Concepts: Validator stake weight](../subnets/understanding-subnets#validator-stake-weight) ### Note on evolution of Bittensor token economy @@ -127,7 +136,7 @@ When Dynamic TAO is initiated, there will be no alpha in circulation, so validat But far more alpha than TAO is emitted into circulation every block. As a result, over time there will be more alpha relative to TAO in overall circulation, and the relative weight of a validator in a given subnet will depend more on their alpha stake share relative to their share of the TAO stake on Subnet Zero. -In order to hasten the process of alpha gaining the majority of stake power in the network, the contribution of TAO stake to validator stake weight is reduced by a global parameter called *TAO weight*. Currently, this is planned to be **18%**, in order to achieve a weight parity between TAO and total alpha in approximately 100 days. +In order to hasten the process of alpha gaining the majority of stake power in the network, the contribution of TAO stake to a validator's stake weight is reduced by a global parameter called _TAO weight_. Currently, this is planned to be **18%**, in order to achieve a weight parity between TAO and total alpha in approximately 100 days.
-
\ No newline at end of file +
diff --git a/docs/miners/index.md b/docs/miners/index.md index 4840719d3..00c08aa48 100644 --- a/docs/miners/index.md +++ b/docs/miners/index.md @@ -9,14 +9,14 @@ import useBaseUrl from '@docusaurus/useBaseUrl'; ## Choosing a subnet -All mining in Bittensor occurs within a subnet. Each subnet independently produces the digital commodities that are its purpose, each subnet creator defining a different _incentive mechanism_ for validators to use in judging miners' work. It is validators scores of miners' performance, according to this incentive mechanism, that determines the proportion of the subnet's emissions allocated to each miner. See [Emissions](../emissions.md). +All mining in Bittensor occurs within a subnet. Each subnet independently produces the digital commodities that are its purpose. Each subnet creator defines a different _incentive mechanism_ for validators to use in judging miners' work. Its validators score miners' performances according to the subnet's incentive mechanism. These scores determine the proportion of the subnet's emissions allocated to each miner. See [Emissions](../emissions.md). -Mining in Bittensor is not like mining Bitcoin or many other blockchains, it is active, creative, and competitive. Preparing to be a subnet miner involves researching the right subnet(s) for _you_ to mine, given your own expertise and access to hardware. +Mining in Bittensor differs significantly from mining Bitcoin or other blockchains. It is active, creative, and competitive. Preparing to be a subnet miner involves researching the right subnet(s) for _you_ to mine, given your own expertise and access to hardware. Browse the subnets and explore links to their code repositories on [TAO.app' subnets listings](https://tao.app). :::tip Typical compute requirements -Each subnet may have distinct hardware requirements, but this [minimum requirements template for subnet creators](https://github.com/opentensor/bittensor-subnet-template/blob/main/min_compute.yml) may give an idea of minimum memory, bandwidth and storage requirements for a typical subnet node. +Each subnet may have distinct hardware requirements, but this [subnet minimum requirements template](https://github.com/opentensor/bittensor-subnet-template/blob/main/min_compute.yml#L14) may give an idea of the minimum memory, bandwidth and storage requirements for miners in a typical subnet node. Mining is not supported on Windows. ::: @@ -26,10 +26,10 @@ Mining is not supported on Windows. To participate as a miner, you must first register a hotkey with the subnet in order to receive a UID on that subnet. :::tip No need to create a subnet to mine -You **do not** have to create a subnet to mine on the Bittensor network. Most miners work on established subnets. +You **do not** have to create a subnet to mine on the Bittensor network. Most miners work on already established subnets. ::: -Registration has a cost in TAO, which fluctuates dynamically based on time since last registration. When you secure a UID slot in a subnet on the main chain, this TAO is sunk cost. +Registration has a cost in TAO, which fluctuates dynamically based on the time since the last registration. When you secure a UID slot in a subnet on the main chain, this TAO is sunk cost and cannot be recovered. A subnet can have a maximum of 64 subnet validator UIDs and 192 subnet miner UIDs (256 total) in subnets other than Subnet 1. @@ -41,14 +41,14 @@ When you delegate your TAO to a subnet validator, you attach your delegated TAO A hotkey can hold multiple UIDs across **separate** subnets. However, within one subnet, each UID must have a unique hotkey. ::: -Run the following command on your terminal, replacing ``, ``, ``. +To register your keys with a subnet, run the following command on your terminal, replacing ``, ``, ``. `` is the `netuid` of your preferred subnet. ```bash btcli subnet register --netuid --wallet.name --wallet.hotkey ``` -For example, for subnet 1 (netuid of 1): +For example, to register your keys with subnet 1—netuid of 1: ```bash btcli subnet register --netuid 1 --wallet.name test-coldkey --wallet.hotkey test-hotkey @@ -56,7 +56,15 @@ btcli subnet register --netuid 1 --wallet.name test-coldkey --wallet.hotkey test ## Miner deregistration -Miners as well as validators can be deregistered if their emissions are low. +A miner can be deregistered if it earns low emissions due to receiving low weights (ratings) from validators. Typical subnets have 256 UID slots per subnet, of which a maximum of 64 subnet can be occupied by validators. Each tempo, the lowest ranked slot is deregistered from the hotkey that holds it and assigned to a new registrant. + +- Every subnet has an `immunity_period` hyperparameter expressed in a number of blocks. + :::tip See + See [`immunity_period`](../subnets/subnet-hyperparameters.md#immunityperiod). + ::: +- A subnet miner or validator at a UID (in that subnet) has a defined number of blocks to improve its performance. This is known as `immunity_period`. When the `immunity_period` expires, that miner or validator can be deregistered if it has the lowest performance in the subnet and a new registration arrives. +- A neuron's `immunity_period` starts when the miner or validator is registered into the subnet. +Validators as well as miners can be deregistered if their emissions are low; either role requires a UID. Typically, subnets have 256 UID slots, with a maximum of 64 slots capable of serving as validators by default. This leaves 192 UIDs for miners, though if there are fewer than 64 eligible validators on a subnet, miners can occupy available slots. @@ -132,7 +140,7 @@ btcli wallet overview --netuid After providing your wallet name when prompted, you will see output such as: -| Parameter | Value | Description | +| Parameter | Example value | Description | | :---------- | :----------------- | :-------------------------------------------------------------------------- | | COLDKEY | my_coldkey | The name of the coldkey associated with your slot. | | HOTKEY | my_first_hotkey | The name of the hotkey associated with your slot. | diff --git a/docs/subnets/create-a-subnet.md b/docs/subnets/create-a-subnet.md index 983ea2809..b318f15ef 100644 --- a/docs/subnets/create-a-subnet.md +++ b/docs/subnets/create-a-subnet.md @@ -127,4 +127,4 @@ Use the below command to start the subnet once `check-start` returns `Emission s ```bash btcli subnet start --netuid x -``` +``` \ No newline at end of file diff --git a/docs/subnets/understanding-subnets.md b/docs/subnets/understanding-subnets.md index a7930a1e8..28c901d3f 100644 --- a/docs/subnets/understanding-subnets.md +++ b/docs/subnets/understanding-subnets.md @@ -7,17 +7,18 @@ import useBaseUrl from '@docusaurus/useBaseUrl'; # Understanding Subnets -In Bittensor, a subnet is an incentive-based competition marketplace that produces a specific kind of digital commodity related to artificial intelligence. It consists of a community of miners that produce the commodity, and a community of validators that measures the miners' work to ensure its quality. Often, parties that serve as validators do so in order to run applications that make use of the services provided by the miners. +In Bittensor, a subnet is an incentive-based competition marketplace that produces a specific kind of digital commodity related to artificial intelligence. It consists of a community of miners that produce the commodity, and a community of validators that measure the miners' work to ensure its quality. Often, parties that serve as validators do so in order to run applications that make use of the services provided by the miners. Emissions of TAO (τ) from Bittensor—are distributed among miners and validators based on their performance within subnets, and based on the relative performance of subnets within Bittensor. ## Anatomy of a subnet The illustration below shows the main components of a subnet: + 1. A subnet's [incentive mechanism](../learn/anatomy-of-incentive-mechanism) defines the work that miners must perform, and the work that validators must perform to evaluate the miners' work. The incentive mechanism is unique to the subnet, and maintained off-chain by the subnet creator in the form of a code-repository that defines the interface for miners and validators to participate. For example, see [Subnet 1](https://github.com/macrocosm-os/prompting). 2. **Miners** perform some useful work as defined in the subnet's incentive mechanism. For example, in Subnet 1, miners serve chat prompt completion. 3. **Validators** independently evaluate the task performed by the subnet miners, according to standards defined by the subnet's incentive mechanism. -4. Validators each score the performance of of each miner over the most recent time period. The matrix of these scores, by each validator for each miner, serves as input to **Yuma Consensus**. +4. Validators each score the performance of each miner over the most recent time period. The matrix of these scores, by each validator for each miner, serves as input to **Yuma Consensus**. 5. The Yuma Consensus algorithm operates on-chain, and determines emissions to miners, validators, and subnet creators across the platform, based on performance.
@@ -33,21 +34,22 @@ style={{width: 600}} ## Subnet liquidity reserves -The key mechanism introduced with Dynamic TAO is that each subnet functions as its own automated market marker (AMM), with two liquidity reserves, one containing TAO($$\tau$$)—the currency of the Bittensor network, and one containing a subnet specific "dynamic" currency, referred to as that subnet's alpha ($$\alpha$$) token. The alpha token is purchased by staking TAO into the subnet's reserve, which is initialized with a negligible amount of liquidity (1e-9). +The key mechanism introduced with Dynamic TAO is that each subnet functions as its own _Automated Market Marker_ (_AMM_), with two liquidity reserves, one containing TAO($$\tau$$)—the currency of the Bittensor network, and one containing a subnet specific "dynamic" currency, referred to as that subnet's alpha ($$\alpha$$) token. The alpha token is purchased by staking TAO into the subnet's reserve, which is initialized with a negligible amount of liquidity (1e-9). A subnet's economy therefore consists of three pools of currency: + - **Tao reserves**: the amount of tao ($$\tau$$) that has been staked into the subnet - **Alpha reserves**: the amount of alpha ($$\alpha$$) available for purchase -- **Alpha outstanding**: the amount of alpha ($$\alpha$$) held in the hotkeys of a subnet's participants, also referred to as the total *stake* in the subnet +- **Alpha outstanding**: the amount of alpha ($$\alpha$$) held in the hotkeys of a subnet's participants, also referred to as the total _stake_ in the subnet :::tip Terminology: alpha tokens Each subnet has its own currency with its own name, but in the abstract a given subnet's token is referred to as its $\alpha$ token. With a set of subnets in mind, we refer to $\alpha$ as the token for subnet $\alpha$, $$\beta$$ as the token for subnet $$\beta$$, $$\gamma$$ as the token for subnet $$\gamma$$, and so on. These subnet tokens contrast with TAO ($$\tau$$), the token of the Bittensor network as a whole. A subnet pool's reserve ratio (tao/alpha) determines the price of its alpha token. ::: -The *price* of a subnet's alpha token is determined by the ratio of TAO in that subnet's reserve to its alpha in reserve. Alpha currency that is not held in reserve but is which is held in the hotkeys of subnet participants is referred to as *alpha outstanding*. +The _price_ of a subnet's alpha token is determined by the ratio of TAO in that subnet's reserve to its alpha in reserve. Alpha currency that is not held in reserve but is which is held in the hotkeys of subnet participants is referred to as _alpha outstanding_. -Run `btcli subnet list` with the Dynamic TAO-enabled `btcli` to view information about the subnets and their currency reserves on Bittensor testnet. +Run the `btcli subnet list` command with the Dynamic TAO-enabled `btcli` to view information about the subnets and their currency reserves on Bittensor testnet. ```txt ┃ ┃ Price ┃ Market Cap ┃ ┃ ┃ ┃ ┃ @@ -61,52 +63,61 @@ Run `btcli subnet list` with the Dynamic TAO-enabled `btcli` to view information 4 │ δ targon │ 0.02 τ/δ │ τ 54.45 │ τ 0.0192 │ τ 30.65, 1.47k δ │ 1.14k δ │ 2.61k δ /21M │ 68/99 ... ``` + See: [Using Dynamic TAO](./index.md#using-dynamic-tao) ## Price/rate of alpha tokens ### Ideal price -For each subnet, you'll see that *Price* (listed in the third column) is a function of TAO in reserve `τ_in` over alpha in reserve `α_in` + +For each subnet, you'll see that _Price_ (listed in the third column) is a function of TAO in reserve `τ_in` over alpha in reserve `α_in` $$ Price = \frac{\tau_{in}}{\alpha_{in}} $$ -For example, if for subnet $\varepsilon$, its subnet pool contains TAO reserves of 1000 TAO units and its alpha reserves of 16000 $\varepsilon$ units, then the relative price of the $\varepsilon$ token is: +
+ See how it's calculated! -$$ -R = \frac{\tau_{in}}{\alpha_{in}} = \frac{1000}{16000} = 0.0625 -$$ + For example, if for subnet $\varepsilon$, its subnet pool contains TAO reserves of 1000 TAO units and its alpha reserves of 16000 $\varepsilon$ units, then the relative price of the $\varepsilon$ token is: -Hence, -$$ -\text{1 } \varepsilon = 0.0625 \text{ TAO} -$$ + $$ + R = \frac{\tau_{in}}{\alpha_{in}} = \frac{1000}{16000} = 0.0625 + $$ + + Hence, + + $$ + \text{1 } \varepsilon = 0.0625 \text{ TAO} + $$ This exchange rate can change every block when staking or unstaking or emissions occur on this subnet. -## Emission in Dynamic TAO +
+ +## Emissions in Dynamic TAO Liquidity is steadily emitted into the Bittensor token economy according to an algorithm intended to foster growth while stabilizing prices and protecting them from manipulation. Each block: + - the chain emits TAO and injects it into the TAO reserves of the subnets. -- the chain emits alpha tokens at twice the base alpha emission rate (which starts at 1 α/block and follows the same halving schedule as TAO). These emitted alpha tokens are allocoated between: +- the chain emits alpha tokens at twice the base alpha emission rate (which starts at 1 α/block and follows the same halving schedule as TAO). These emitted alpha tokens are allocated between: - the subnet's alpha reserve (increasing available liquidity) - alpha outstanding (incentives for miners, validators, and subnet creators) -See the main article: [Emission in Dynamic TAO](../emissions.md) +See the main article: [Emissions in Dynamic TAO](../emissions.md) ## Decentralized evaluation of subnets -The relative value or *weight* of subnets within Bittensor is critically important as it determines emissions to different subnets and their participant miners and validators. Prior to Dynamic TAO, relative weight among subnets within the Bittensor network were determined by Yuma Consensus over the evaluations of the Root Network validators. This gives a fundamentally centralizing role to the holders of Root Network validator keys. +The relative value or _weight_ of subnets within Bittensor is critically important as it determines emissions to different subnets and their participant miners and validators. Prior to Dynamic TAO, relative weight among subnets within the Bittensor network were determined by Yuma Consensus over the evaluations of the Root Network validators. This gives a fundamentally centralizing role to the holders of Root Network validator keys. In Dynamic TAO, the relative weight is determined organically according to the emergent market value of the subnet, as represented by its stabilized token price. TAO-holders can stake TAO into subnets in exchange for the subnet-specific dynamic currency, referred to as the subnet's alpha ($$\alpha$$) token. In this way, stakers 'vote with their TAO' for the value of the subnet, determining the emissions to the validators and miners working in it. In return, stakers extract a share of the subnet's emissions. ## Subnet Zero -In Dynamic TAO, Subnet Zero—or *Root Subnet*—is a special subnet. It is the only subnet that does not have its own $\alpha$ currency. No miners can register on subnet zero, and no validation work is performed. However validators can register, and $\tau$-holders can stake to those validators, as with any other subnet. This offers a mechanism for $\tau$-holders to stake $\tau$ into validators in a subnet-agnostic way. This works because the weight of a validator in a subnet includes both their share of that subnet's $\alpha$ and their share of TAO staked into the root subnet. in Subnet Zero. +In Dynamic TAO, Subnet Zero—or _Root Subnet_—is a special subnet. It is the only subnet that does not have its own $\alpha$ currency. No miners can register on subnet zero, and no validation work is performed. However validators can register, and $\tau$-holders can stake to those validators, as with any other subnet. This offers a mechanism for $\tau$-holders to stake $\tau$ into validators in a subnet-agnostic way. This works because the weight of a validator in a subnet includes both their share of that subnet's $\alpha$ and their share of TAO staked into the root subnet. Over time, the emissions generated by TAO staked into Subnet Zero will decrease, relative to stake held in the alpha currency of active subnets. See [Note on evolution of Bittensor token economy](../emissions.md#note-on-evolution-of-bittensor-token-economy). @@ -116,9 +127,11 @@ A validator's stake weight in a subnet equals their alpha stake plus their TAO s $$ -\text{Validator stake weight} = \text{Alpha stake} (\alpha) + \text{TAO stake} (\tau) \times \text{TAO weight} +\text{Validator stake weight} = \text{Alpha stake} (\alpha) + \text{TAO stake} (\tau) \times \text{TAO weight} + $$ + :::tip A validator's stake weight in Subnet Zero is simply their staked TAO. ::: @@ -127,9 +140,10 @@ A validator's relative stake weight (their stake weight over the total stake wei $$ -\text{Validator x's relative stake weight} +\text{Validator x's relative stake weight} = \frac{\alpha_x + \tau_x \times w_{\tau}} {\displaystyle \sum_{v \in \text{validators}} \bigl(\alpha_v + \tau_v \times w_{\tau}\bigr)} + $$ diff --git a/docs/validators/index.md b/docs/validators/index.md index 2c3906347..b4946d243 100644 --- a/docs/validators/index.md +++ b/docs/validators/index.md @@ -7,12 +7,12 @@ import useBaseUrl from '@docusaurus/useBaseUrl'; # Validating in Bittensor -All mining and validating in Bittensor occur within a subnet. Each subnet independently produces the digital commodities that are its purpose, each subnet creator defining a different _incentive mechanism_ for validators to use in judging miners' work. The validator's work is to apply this incentive mechanism to miners, using it to score their performance, and then to submit these weights to the Bittensor blockchain. It is validators scores of miners' performance that determines the proportion of the subnet's emissions allocated to each miner, according to the Yuma Consensus algorithm. See [Emissions](../emissions.md). +All validating in Bittensor occurs within a subnet. Each subnet independently produces the digital commodities that are its purpose, with each subnet creator defining a different _incentive mechanism_ for validators to use in judging miners' work. The validator's work is to apply this incentive mechanism to miners, using it to score their performance, and then to submit these weights to the Bittensor blockchain.  The validator scores of miners' performance determine the proportion of the subnet's emissions allocated to each miner, according to the Yuma Consensus algorithm. See [Emissions](../emissions.md). Browse the subnets and explore links to their code repositories on [TAO.app' subnets listings](https://tao.app). :::tip Typical compute requirements -Each subnet may have distinct hardware requirements, but this [minimum requirements template for subnet creators](https://github.com/opentensor/bittensor-subnet-template/blob/main/min_compute.yml) may give an idea of minimum memory, bandwidth and storage requirements for a typical subnet node. +Each subnet may have distinct hardware requirements, but this [subnet minimum requirements template](https://github.com/opentensor/bittensor-subnet-template/blob/main/min_compute.yml#L49) may give an idea of the minimum memory, bandwidth and storage requirements for validators in a typical subnet node. Validating is not supported on Windows. ::: @@ -32,7 +32,7 @@ The number of validators isn't hardcoded. The subnet governor has the authority To have a **validator permit** in a given subnet, you must meet the following requirements: - Your hotkey must be registered, granting you a UID on the subnet -- You must have a stake-weight on the subnet of least 1000, including stake delegated to your hotkey from other wallets' coldkeys. A validator's stake weight in a subnet equals their alpha stake plus their TAO stake times the `tao_weight` parameter (current value: 0.18): +- You must have a stake-weight on the subnet of least 1000, including stake delegated to your hotkey from other wallets' coldkeys. A validator's stake weight in a subnet equals their alpha stake plus their TAO stake multiplied by the `tao_weight` parameter (current value: 0.18): $$ @@ -42,12 +42,14 @@ To have a **validator permit** in a given subnet, you must meet the following re - You must be one of the top 64 nodes in the subnet, ranked by emissions. -## Hotkey Association & Staking (subnet 0, the root subnet, only) +## Hotkey Association & Staking :::tip Root Subnet (Subnet 0) only -Skip this step if you are not registering a validator on the root subnet (subnet 0) +This step is only required if you are registering on the root subnet (Subnet O). Skip this step if you are not registering a validator on the root subnet. ::: +To become a validator on the root subnet, you must first associate your hotkey and then stake funds to your hotkey account within the subnet. To associate your hotkey: + ```bash btcli wallet associate-hotkey --wallet.name --hotkey ``` @@ -107,7 +109,7 @@ A subnet neuron (miner or validator) at a UID (in that subnet) has `immunity_per A validator's consensus weight and emissions depend on their hotkey's stake weight. You can stake your own TAO to your validator hotkey, or advertise your hotkey to others and seek stake. Any wallet's coldkey can stake to any hotkey, subsequently receiving emissions from that stake. :::tip Delegation -See [StakingDelegation](../staking-and-delegation/delegation.md) +See [Staking and Delegation](../staking-and-delegation/delegation.md) ::: ### Add stake @@ -151,7 +153,7 @@ btcli wallet overview --netuid After providing your wallet name at the prompt, you will see output like: -| Parameter | Value | Description | +| Parameter | Example value | Description | | :---------- | :----------------- | :------------------------------------------------------------------------- | | COLDKEY | my_coldkey | The name of the coldkey associated with your slot. | | HOTKEY | my_first_hotkey | The name of the hotkey associated with your slot. | diff --git a/docs/yuma-consensus.md b/docs/yuma-consensus.md index c5e57c42e..eb95059f1 100644 --- a/docs/yuma-consensus.md +++ b/docs/yuma-consensus.md @@ -6,13 +6,14 @@ title: "Yuma Consensus" ## Introduction -Yuma Consensus (YC) is a critical algorithmic process within Bittensor, which runs on-chain within Subtensor. Its responsibility is to compute validator and miner emissions from validators' rankings of miners. +Yuma Consensus (YC) is a critical algorithmic process within Bittensor, which runs on-chain within Subtensor. Its responsibility is to compute validator and miner emissions from validators' rankings of miners' performances. -Each of a subnet's validators periodically submit a vector of weights ranking the value of the work of each miner they've evaluated. The YC algorithm resolves this matrix of rankings into two **emissions vectors** that allocate emissions over participants based on their performance: one each for **miners** and **validators**. +Each of a subnet's validators periodically submits a vector of weights ranking the value of the work of each miner they've evaluated. The YC algorithm resolves this matrix of rankings into two **emissions vectors**—one each for **miners** and **validators**. These emissions vectors allocate emissions over participants based on their performances. The algorithm is designed to more heavily weight the inputs of more trusted validators, in order to ignore the portion of the validation signal that is less reliable. By disregarding unreliable weight-settings, YC incentivizes validators to be worthy of trust by working hard to give consistent, fast, honest evaluations of miners that predict the eventual convergence of other validators' evaluations. YC incentivizes miners to work hard for the highest combined evaluation by the community of validators. See: + - [Emissions](./emissions) - [Subtensor Docs: Yuma Consensus](https://github.com/opentensor/subtensor/blob/main/docs/consensus.md) @@ -20,14 +21,17 @@ See: Clipping is designed to punish innacurate miner evaluation, especially in patterns that could constitute collusion to manipulate the accuracy of consensus to favor certain miners. -To achieve this, the judgment of the most trusted validators (as measured by stake) serves as a benchmark. Weights that exceed this benchmark are *clipped*, meaning neither the miner nor the validator receives emissions for them. +To achieve this, the judgment of the most trusted validators (as measured by stake) serves as a benchmark. Weights that exceed this benchmark are _clipped_, meaning neither the miner nor the validator receives emissions for them. This clipping protects against erroneous or collusive over-evaluation of miners by validators. +
+ See how it's calculated + To compute the benchmark $\overline{W_j}$ for miner $j$ and set $\mathbb{V}$ of the subnet's validators, we gather all validator weights $W_{ij}$ for any validator $i \in \mathbb{V}$, sort them by validator’s **stake** $S_i$, and then find the maximum weight level $w$ supported by at least a fraction $\kappa$ of total stake. $$ -\overline{W_j} = \arg \max_{w} +\overline{W_j} = \arg \max_{w} \Bigl(\, \sum_{i \in \mathbb{V}} S_i \,\cdot\, \bigl\{\,W_{ij}\,\ge w \bigr\} \ge \kappa \Bigr). @@ -42,14 +46,18 @@ $$ :::tip note Kappa is a configurable hyperparameter with default: $\kappa = 0.5$. -This means that if *least* generous half (0.5) of the validators (with each validator measured by stake, not 1 per validator) set weights for a given miner to no more than x, then the weights of the other, more generous, half of the validators for that miner are going to be clipped down to x. 'Generous' here refers to giving a high weight to the miner in question. +This means that if _least_ generous half (0.5) of the validators (with each validator measured by stake, not 1 per validator) set weights for a given miner to no more than x, then the weights of the other, more generous, half of the validators for that miner are going to be clipped down to x. 'Generous' here refers to giving a high weight to the miner in question. ::: +
+ ## Miner emissions Miner emissions are based on an aggregate ranking which is the summed rankings of validators, weighted by validators' stake, where $\overline{W_{ij}}$ is the post-clip weight. -$$ +
+ See how it's calculated + $$ R_j = \sum_{i \in \mathbb{V}} S_i \,\cdot\, \overline{W_{ij}} $$ @@ -59,25 +67,35 @@ $$ M_j = \frac{\,R_j\,}{\sum_{k \in \mathbb{M}} R_k} $$ +
+ ## Penalizing out-of-consensus bonds If a validator's evaluation of a miner is too high, it is penalized. If a submitted weight $W_{ij}$ by validator $i$ for miner $j$ exceeds the $j$'s consensus evaluation, $\overline{W_j}$, its bond value is penalized by factor $\beta$. +
+ See how it's calculated + Bond-weight $\widetilde{W_{ij}}$ is: $$ -\widetilde{W_{ij}} +\widetilde{W_{ij}} = (1-\beta)\,W_{ij} +\beta\,\overline{W_{ij}} $$ :::tip note -Penalty factor $\beta$ is a configurable hyperparameter. +Penalty factor $\beta$ is a configurable hyperparameter. ::: +
+ ## Bonding mechanics The **instant bond** $\Delta B_{ij}$ of validator $i$ to miner $j$ is equal to $i$’s stake, $\,S_i$ times $i$'s bond-weight for $j$ normalized by $j$'s total bond-weight for all $\mathbb{V}$ of the subnet's validators: +
+ See how it's calculated + $$ \Delta B_{ij} = \frac{\,S_i \,\cdot\, \widetilde{W_{ij}}\,}{ \sum_{k \in \mathbb{V}} S_k \,\cdot\, \widetilde{W_{kj}}} @@ -89,15 +107,18 @@ $$ B_{ij}^{(t)} = \alpha \,\Delta B_{ij} + (1-\alpha)\,B_{ij}^{(t-1)} $$ -Validators who stay near consensus build stronger EMA bonds and thus extract more emissions, while any attempt to overstate a particular miner’s performance is penalized. The EMA smooths out abrupt swings in validator behavior and incentivizes consistent alignment with the consensus. - :::tip note The $\alpha$ variable here is unrelated to the concept of subnet specific currencies, referred to as alpha $\alpha$ tokens. Here $\alpha$ refers to a factor used in this EMA smoothing function—see [consensus-based weights, a.k.a. liquid alpha](./subnets/consensus-based-weights.md). ::: +
+ +Validators who stay near consensus build stronger EMA bonds and thus extract more emissions, while any attempt to overstate a particular miner’s performance is penalized. The EMA smooths out abrupt swings in validator behavior and incentivizes consistent alignment with the consensus. + ## Validator emissions Each validator $i$’s share $V_i$ of validator emissions (41% of each subnet's total emissions) is the sum of all of its bonds to miners, weighted by the miner's total emissions: + $$ V_i = \sum_{j \in \mathbb{M}} \Bigl(\,B_{ij} \,\times\, M_j\Bigr) -$$ \ No newline at end of file +$$