This episode explores the upcoming Yuma 3 (YC3) consensus upgrade for BitTensor, detailing its mechanics and sparking debate on its potential to reshape validator competition and subnet security.
Introducing Ref: A Key BitTensor Developer
- The host introduces Ref, a highly knowledgeable and active developer within the BitTensor ecosystem.
- Ref's significant contributions include writing Commit Reveal 2 (with version 3 in deployment), leading the Church Route Discord for developers, driving efforts against weight copying, and running one of the first compute subnets (Subnet 12).
- He also created widely used tools like the Grafana Back Tensor dashboard.
- The host shares a personal anecdote about initially hiring and firing Ref from Upwork, only for Ref to become a core contributor.
The Evolution of Yuma Consensus: From YC1 to YC3
- The host provides context on BitTensor's consensus mechanisms, starting with Yuma Consensus 1 (YC1) outlined in the whitepaper, which proved flawed.
- YC2, introduced by Taco, improved upon YC1 by adding bonds, significantly hindering validator-side exploits. Bonds are a mechanism requiring participants (validators/miners) to lock up capital (Tao), which can be penalized (slashed) for malicious behavior or poor performance, aligning incentives with network health.
- However, YC2's primary issue is its myopic focus on validator agreement rather than agreement based on actual validation work. This created loopholes for "weight copiers"—validators who mimic others' weights without performing validation, thus earning rewards for no work. Weight Copying refers to validators setting their influence (weights) on miners by copying the weights of other validators, rather than performing the independent validation work required by the subnet.
- Ref explains that his work on Commit Reveal and YC3 aims to address these fundamental flaws, particularly the plague of weight copying.
Introducing the Collateral Smart Contract: Raising the Stakes for Miners
- Ref introduces a new Collateral Smart Contract, designed to combat miner cheating within subnets.
- Currently, miners can exploit subnets, farm emissions (rewards), and exit before facing consequences. The new contract requires miners to pay a security deposit (e.g., 5 Tao) to participate.
- If a miner is caught cheating by validators, this collateral is burned, introducing a direct financial cost to malicious behavior.
- This is the first smart contract tightly integrated with subnet logic, requiring new features in the subtensor (BitTensor's core blockchain component).
- Ref notes the technical complexity involving different key types (standard SS58 Polkadot keys and EVM-compatible H160 keys for smart contracts) but assures that scripts will simplify miner interaction. EVM (Ethereum Virtual Machine) is a computation engine that executes smart contracts on Ethereum and compatible chains; H160 is the address format used within the EVM. SS58 is the address format used by Substrate-based chains like Polkadot and BitTensor.
- A dashboard has been built to monitor collateral, demonstrating successful tests where cheating miners had their collateral burned. This mechanism aims to disincentivize cheating, especially for accessing "organic tasks" (real user tasks).
Deep Dive into Yuma 3 (YC3): Rewarding Eager Validators
- Ref explains the core problem YC3 solves by contrasting it with YC1 and YC2 using simulation charts.
- In YC1, large validators disproportionately benefit, even if smaller validators are quicker or more accurate in identifying the best miners.
- YC2 attempted to fix this but inadvertently penalizes "eager" validators who are first to identify and vote for a new top-performing miner. Ref discovered this anomaly by analyzing real network data (Subnet 9), where the first validator to switch was penalized, while the largest validator still gained the most. Ref states, "Turns out Yuma 2 doesn't really work the way we all thought it works."
- YC3 is designed to reward the validator who first discovers the new leading miner. While there might be a small initial dip in dividends (as the system verifies the move isn't collusion), the eager validator receives significantly higher dividends once consensus shifts.
- The reward curve in YC3 is adjustable via hyperparameters, allowing subnet owners to tune the mechanism. A simulator tool will be provided for users to test different scenarios.
Liquid Alpha 2.0: Enhancing Validator Accountability
- Liquid Alpha 2.0 refines the mechanism for adjusting the rate at which validators acquire bonds based on their performance.
- While Liquid Alpha 1.0 showed some correlation with rewarding honest miners, it had edge cases where it worsened outcomes.
- Version 2.0 accurately adjusts bond acquisition rates, penalizing validators who are late in setting weights (reflecting the current state of miner performance).
- This increases pressure on validators to be vigilant, maintain their infrastructure (memory, node monitoring), and set weights promptly. Delays harm the ecosystem by slowing down the network's response to changes in miner quality.
Ecosystem Implications: A New Era of Validator Competition
- Ref argues that YC3 and Liquid Alpha 2.0 usher in an era where validators compete not just on cost-effective hardware but on performance and accuracy.
- Validators who are late will be penalized, while those who are early and accurate in identifying top miners will be rewarded with higher APY (Annual Percentage Yield, referring to dividend returns here).
- Ref uses Subnet 7 as an example where the current incentive design is flawed, allowing predictable weight increases for newly registered miners. Faster validators could identify true quality sooner but aren't properly incentivized under YC2. YC3 aims to reward this speed and accuracy.
- He also points to Subnet 9 patterns that resemble weight copying, suggesting YC3, combined with Commit Reveal and Liquid Alpha 2.0, could drive these actors out.
Compute Horde (Subnet 12): Decentralizing Validation Compute
- Ref details Compute Horde (Subnet 12), which allows validators on other subnets to utilize the GPU resources of SN12 miners for their validation tasks.
- The Collateral Smart Contract is crucial here, preventing SN12 miners from faking computation results (cheaters get collateral burned). Work is cross-verified.
- To use Compute Horde, validation tasks must be "Horized"—packaged into Docker containers without network access (models provided as volumes) to ensure verifiability. An SDK is available.
- This enables validators to use variable amounts of compute (e.g., 10 GPUs for 5 minutes) rather than dedicating fixed GPUs, offering flexibility and cost-efficiency, especially as the number of subnets grows.
- Validators can parallelize tasks across multiple GPUs sourced from Compute Horde, limited only by their effective stake in SN12.
- A fallback mechanism to use commercial providers like RunPod is being developed for redundancy.
- Ref contrasts this practical, deployable solution with the current limitations of TE (Trusted Execution Environments), which are hard to set up at scale, and ZK (Zero-Knowledge proofs), which are currently too slow for high-performance validation.
DOS Shield: Enhancing Miner Security
- Ref introduces the DOS Shield, a mechanism to protect miners from DoS (Denial of Service) attacks originating from validators.
- Miners generate unique IP addresses for each validator, encrypt them with the validator's public key, and publish them.
- Validators decrypt only the IP meant for them. If a validator attacks a miner using this unique IP, the miner knows the attacker's identity.
- The miner can then easily block that specific validator and regenerate IPs for the remaining ones, preventing further attacks from that source without impacting overall service. This also prevents miners from discovering each other's IPs.
Community Discussion: Concerns and Debates on YC3
- Capricious's Concerns: Centralization and Infrastructure Reliance
- Capricious (a major validator operator) expresses concerns about YC3 potentially exacerbating validator centralization, especially on subnets with few independent validators (often just Rizzo, RoundTable, Yuma, and the owner).
- He worries weight copiers might simply shift to child hotkeying (delegating stake) to dominant owner validators, further concentrating power. Child Hotkeying allows a validator to run operations using a separate key (child hotkey) while the main key (parent) holds the stake, simplifying delegation but potentially obscuring the true operator.
- He raises concerns about Compute Horde becoming a central point of failure if widely adopted, forcing reliance on it or third-party providers like RunPod, undermining efforts towards self-reliant infrastructure (like his "apocalypse proof bunker"). He notes the awkwardness of having to register his own GPUs as an SN12 miner to then "rent" them back for validation.
- The Weight Copier Debate: Incentivizing Accuracy or Cheating?
- A major debate erupts regarding whether YC3 inadvertently rewards sophisticated weight copiers.
- Fish and Capricious argue that validators using predictive models to anticipate honest validator weights faster are essentially cheating, building their success on the real work of others. Capricious asks, "Why would you want a system that just incentivizes the cheater?"
- Ref counters that if a system's weights are predictable, the subnet design itself is flawed. He argues that accurately determining miner quality faster is better validation, regardless of method. If prediction works, it implies the underlying process is too simple or slow. The solution, he suggests, is less predictable subnet mechanics and tools like Commit Reveal.
- Fish's Perspective: Questioning the Necessity and Burden of YC3
- Fish (representing a subnet owner perspective) pushes back strongly, arguing YC3 imposes a significant burden. He feels it turns validation into "double-sided mining," requiring constant optimization and defense against new validator attack vectors.
- He questions the need for YC3 if the YC2 problems (like penalized eager validators) aren't critically impacting his specific subnet, especially if weight copying is already managed through other means. Fish states, "If validators are changing the validator code they're no longer validating... They're mining..."
- He advocates for fixing potential bugs in YC2 rather than adopting YC3's complexity, unless the pain point of YC2 becomes unavoidable for his subnet.
- Hotkey Splitting: A Necessary Prerequisite?
- Capricious highlights that monolithic validators (using a single hotkey across multiple subnets) will be disadvantaged by YC3's time sensitivity due to chain limitations (one weight-set per block per hotkey).
- He stresses the urgency of the "hotkey splitting" feature (allowing validators to switch subnets to different hotkeys without re-registering/paying fees) to mitigate this, referencing Yuma's costly and painful manual split. Without it, validators like himself and Rizzo risk being "kneecapped."
Looking Ahead: The Path to YC3 Adoption
- YC3 is live on testnet, with a mainnet deployment anticipated early the following week.
- Crucially, YC3 will initially be configurable; subnet owners can choose to run YC1, YC2, or YC3 via a hyperparameter, allowing for gradual adoption and testing.
- Ref emphasizes that YC2 has fundamental flaws that YC3 aims to fix, suggesting YC2 might eventually be deprecated.
- The detailed technical debate, particularly around YC2 bugs vs. YC3 benefits/drawbacks, is scheduled to continue in the next Open Dev community call.
The YC3 upgrade aims to reward validator accuracy but sparks debate on incentivizing prediction ('copying') and increasing subnet complexity. Investors/researchers must monitor its adoption, impact on validator dynamics (especially competition and potential centralization), and the evolution of subnet incentive mechanisms to stay ahead.
