Bittensor uses a subjective utility consensus mechanism called Yuma Consensus which rewards subnet validators with scoring incentive for producing evaluations of miner-value which are in agreement with the subjective evaluations produced by other subnet validators weighted by stake. Subnet servers receive incentive for their share of the utility according to the subnet validator consensus. Yuma Consensus pertains to subnet validation, instead of blockchain validation (substrate), so this writing will always refer to subnet validators and servers.
How do we automatically detect and penalize reward manipulation in high-volume subjective utility networks?
Most utility networks serve objectively measurable utility, such as data storage (Filecoin, Siacoin, Storj, Arweave), computation (Golem, TrueBit, Flux, Render, iExec RLC, Near), wireless networking (Helium), video streaming (Theta, Livepeer), and music streaming (Audius). Each of these networks employs specific, quantifiable metrics for their services, ranging from gigabytes of storage and CPU/GPU cycles to network coverage, bandwidth utilization and streaming quality.
Objectively measurable utility makes it easy to detect and penalize reward manipulation, without the need for sophisticated consensus. Cryptographic proofs verify storage claims (Filecoin, Siacoin), outlier detection identifies and isolates inaccurate assessments (Ocean), cross-validation by multiple independent oracles reduce impact of single dishonest oracle (Chainlink), redundant computation prevents false result validation (Golem, TrueBit), random checks and challenges ensure honesty in computation results evaluation (iExec RLC), and continuous verification of actual network coverage (Helium). Objective utility networks typically need only basic majority consensus to correct malicious validation.
Subjective utility networks (such as Steemit, Hive, LBRY, Minds, Voice, etc.) typically revolve around community-generated and curated content. Lower-volume content production allows for manual voting and tipping by users, or measurements of user and viewer engagement to calculate rewards. These subjective utility networks predominantly rely on manual mechanisms for reward distribution and detection of malicious activity. Community-driven reporting and moderation (Steemit, Hive, Minds), manual content evaluation (LBRY, Voice), and real identity verification (Voice) deter and penalize reward manipulation.
Community oversight (as in Steemit) must identify wrongful downvoting, but only indirect remediation via counter-voting can penalize bad actors. The absence of voting reputation means users can only downvote the content of bad actors as retribution and thereby only damage content reputation, because no automated penalty mechanism exists. Similarly, users can upvote their own content and potentially receive nominal reward according to their stake, so reward manipulation may go unchecked.
High-volume, on-demand generative content (as in Bittensor) demands automated evaluation and divide-and-conquer validation, but introduces subjectivity both in the automated value measures and mutually exclusive task subsets across subnet validators. A coalition of validators can collude to skew scoring of subnet servers in their favour, which is harder to detect because of the inherent subjectivity. Existing consensus mechanisms will fail to deter reward manipulation for such high-volume subjective utility networks, so the need for a more sophisticated consensus arises.
Yuma Consensus guarantees long-term network honesty despite persistent adversarial presence in high-volume subjective utility networks. It directly penalizes selfish scoring by down-correction to the majority consensus and slashing of cabal voting stake, and also penalizes low-scoring of honest servers via forfeited validator rewards when cabals don’t score at consensus.
Yuma Consensus is adversarially-resilient when majority stake is honest, via stake-based median scoring that punishes selfish weighting by minority stake (cabal). We clip excess weight above the maximum weight supported by at least
Max weight supported by
Cabal sets low weight on honest majority: The median calculation ignores selfish subsets that vote dishonestly (cabals), if they have minority stake (less than
Cabal sets high self-weight: Cabal servers with poor utility will receive low weights from majority stake, and high self-weight from minority cabals will then get reduced to the low consensus. This means that minority cabals lose voting power as penalty for unfair voting while still receiving low consensus weight despite high self-weight. This consensus mechanism thus protects against selfish weighting if the majority stake is honest.
We consider a two-team game between (protagonist) honest stake (
We assume honest stake sets objectively correct weights
The cabal has the objective to maximize the required honest self-weight expense
We then assume the honest majority
Majority stake enforces an independent and anonymous consensus policy
We propose a consensus policy that uses stake-based median as consensus weight
The consensus policy applies weight correction
A subnet validator
Emission ratio
Subnet server incentive
Validation reward
| Variable | Equation | Description |
|---|---|---|
| Weight | Validator |
|
| Stake | Validator |
|
| Server prerank | Sum of weighted stake. | |
| Server consensus weight |
|
|
| Consensus-clipped weight | Validator |
|
| Server rank | Sum of consensus-clipped weighted stake. | |
| Server incentive | Ratio of incentive for server |
|
| Server trust | Relative server weight remaining after consensus-clip. | |
| Validator trust | Relative validator weight remaining after consensus-clip. | |
| Bonds penalty | Degree to cut bonds above consensus weight. | |
| Weight for bonds | Apply bonds penalty to weights. | |
| Validator bond | Validator |
|
| Validator EMA bond | Validator |
|
| Validator reward | Validator |
|
| Emission ratio | Reward/incentive ratio for emission | |
| Emission | Emission for node |
Subtensor blockchain nodes calculate consensus and rewards during each subnet epoch with associated code excerpts as follows.
let mut weights: Vec<Vec<I32F32>> = Self::get_weights( netuid ); // Weight
let preranks: Vec<I32F32> = matmul( &weights, &active_stake ); // Server prerank
let consensus: Vec<I32F32> = weighted_median_col( &active_stake, &weights, kappa ); // Server consensus weight
inplace_col_clip( &mut weights, &consensus ); // Consensus-clipped weight
let mut ranks: Vec<I32F32> = matmul( &weights, &active_stake ); // Server rank
let trust: Vec<I32F32> = vecdiv( &ranks, &preranks ); // Server trust
let validator_trust: Vec<I32F32> = row_sum( &weights ); // Validator trust
let incentive: Vec<I32F32> = inplace_normalize( &mut ranks ); // Server incentive
let mut bonds_delta: Vec<Vec<I32F32>> = inplace_col_normalize(row_hadamard( &weights, &active_stake )); // Validator bond
let mut ema_bonds: Vec<Vec<I32F32>> = mat_ema( &bonds_delta, &bonds, alpha ); // Validator EMA bond
let mut dividends: Vec<I32F32> = inplace_normalize(matmul_transpose( &ema_bonds, &incentive )); // Validator rewardWe consider a two-team game between (protagonist) honest stake (
A network size of
For the Monte Carlo simulations we use Gaussian distributions for stake and weight assignments, and ensure that the honest/cabal ratios are met. Note that stake is only assigned to validator nodes
Firstly, we sample initial validator (
Then we normalize each honest/cabal subset and multiply by its stake proportion, which thus gives an overall normalized stake and the correct stake ratio for each subset:
Similarly, we randomize the weights that validators
We firstly sample initial weights
Weight setting between the two subsets forms quadrants
Given the simulation parameters of the network size, validator count, a defined major/honest stake
We calculate the consensus
To calculate emissions for this epoch, we firstly calculate server rank
Then we add up server incentive and validator bonds over honest nodes to obtain honest emission
The honest objective
Yuma Consensus guarantees honest majority stake retention
Consensus guarantees are dependent on stake, utility, and subnet validator behaviour, so we use 2D contour plots to comprehensively display guarantees across each possible set of conditions.
The x-axis is major self-weight and the y-axis is minor self-weight, and each contour line is a specific major stake.
Major/honest self-weight
To understand how we construct these plots, let us first consider contour plot for a single major/honest stake setting
Similarly, the specific emission contour plot for
A compound plot then combines all the highlighted
Retention graphs like these comprehensively capture consensus guarantees across all primary conditions, and we utilize these to analyze the effect of consensus hyperparameters. Subtensor integration tests run Monte Carlo simulations of large realistic networks under adversarial conditions, and constructs retention profiles to confirm consensus guarantees of the actual blockchain implementation.
Retention profiles are reproducible by running test map_consensus_guarantees() and plotting with map_consensus.py.
RUST_BACKTRACE=1 SKIP_WASM_BUILD=1 RUSTFLAGS="-C opt-level=3" cargo test --manifest-path=pallets/subtensor/Cargo.toml -- tests::consensus::map_consensus_guarantees <bonds_penalty> --exact --nocapture > consensus.txt
python scripts/map_consensus.py consensus.txtYuma Consensus corrects reward manipulation in subjective utility networks, but the extent of subjectivity influences the exact consensus guarantees. In particular, we expect lower subjectivity to offer improved guarantees since there is stronger consensus. However, for higher variance in assigned weights it is easier to hide reward manipulation, we then expect poorer guarantees.
We assume normally distributed weights originating from a particular side, either honest or cabal, then we modify the weight deviation magnitude
Bitcoin has its well-known 51% attack, while Yuma Consensus has a 40% stake + 30% utility attack under high subjectivity (
Hyperparameter Kappa sets the ratio of stake that decides consensus, with a typical recommended value of
Yuma Consensus separately adjusts server incentive
We expect that greater bonds penalty will penalize out-of-consensus validators more, which means less emission going to cabals. Comprehensive simulation with
Subnet servers need incentive to deliver high utility, and subnet validators need rewards to secure the network. We expect that more emission going to validators will improve security guarantees, since self-serving validation can then be economically disincentivized.
We set validation reward ratio at
This guide demonstrates how to reproduce consensus retention profile plots on a minimal Runpod CPU instance.
Navigate to https://www.runpod.io/console/deploy and select the following:
- Pod Type: CPU Pod, CPU5 (5.7 GHz • DDR5 RAM • NVMe) or equivalent.
- Instance Configuration: Compute-Optimized ($0.07/hr, 2 vCPUs, 4GB RAM).
Important: Edit the template and set "Container Disk (Temporary)" to 20GB. This ensures sufficient disk space for the process.
Retrieve the connection details, including the SSH command and port, under "Connect" -> "SSH over exposed TCP". You can optionally enable Jupyter access (8888:localhost:8888) if desired. Connect to your instance via SSH:
ssh -L 8888:localhost:8888 root@<your_vps_ip_address> -p <your_vps_port> -i ~/.ssh/id_ed25519 # Replace placeholders-
Start a
tmuxsession for persistence:tmux
-
Update system packages and install prerequisites (Python, Rust, and dependencies):
sudo apt-get update && sudo apt install -y build-essential clang curl git make libssl-dev llvm libudev-dev protobuf-compiler python3 python3-pip \ && curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh -s -- -y \ && source ~/.cargo/env && rustup default stable && rustup update \ && rustup target add wasm32-unknown-unknown \ && rustup toolchain install nightly \ && rustup target add --toolchain nightly wasm32-unknown-unknown
-
Clone the Subtensor repository and checkout the relevant branch:
git clone https://github.com/opentensor/subtensor.git cd subtensor git checkout main
The Subtensor integration tests simulate large, realistic networks under adversarial conditions to generate retention profiles that validate the blockchain's consensus guarantees. Building takes about 10 minutes, and the actual test itself another 15 minutes approximately.
RUST_BACKTRACE=1 SKIP_WASM_BUILD=1 RUSTFLAGS="-C opt-level=3" cargo test --manifest-path=pallets/subtensor/Cargo.toml -- tests::consensus::map_consensus_guarantees <bonds_penalty> --exact --nocapture > consensus.txtThis command runs the map_consensus_guarantees test and saves the output to consensus.txt. Replace <bonds_penalty> with a float e.g. 1.0 (100% bonds penalty).
-
Create a Python virtual environment and install necessary libraries:
python3 -m venv .venv source .venv/bin/activate pip install numpy matplotlib jupyterlab -
Run the plotting script:
python3 scripts/map_consensus.py consensus.txt
This generates an SVG file named
consensus_plot.svgin the current directory.
You can use Jupyter-lab to interactively explore and modify the generated plots:
-
Start Jupyter-lab (on VPS):
jupyter-lab --allow-root --port=8888
-
Connect to Jupyter: Open the provided URL (e.g.,
http://localhost:8888/tree?token=...) in your local workstation web browser. -
Modify the plotting script: Edit
scripts/map_consensus.pyto customize the plots, otherwise download the SVG file.
This reproduction procedure is provided as a guide and may require adjustments depending on your specific VPS environment and configuration. While every effort has been made to ensure accuracy and completeness, variations in system setup, software versions, or network conditions could affect the results.
Please exercise caution when executing commands with root privileges and ensure you understand the potential implications before proceeding. The author assumes no responsibility for any issues arising from the use of this procedure. If you encounter problems or have suggestions for improvement, please open an issue on this repository.
