Proof-of-Weights

Omron brings an important proposal to Bittensor; Proof of Weights.

Introduction

Proof of Weights is designed to enhance validator performance by ensuring certainty, efficiency, and transparency. Certainty is achieved through zero-knowledge cryptographic proofs, enabling everyone to verify the computations performed by validators. Efficiency is optimized as validators can save bandwidth by using these proofs to confirm correct computations and copy weights. Transparency is maintained as Subnet 2 validators are compensated by Subnet 2 (Omron) for the bandwidth and costs incurred to publish the cryptographic proofs on-chain. SN2 Validators will be able to claim TAO monthly for the transaction costs associated. This milestone advances our roadmap towards building trustless validators using cryptography.

The problem

Validators may choose to participate in "weight copying" and subnet operators may elect to allow "weight copying" to improve the efficiency and bandwidth of Validators. Weight copying allows a validator to copy the weights from validators performing the computational work, and submit averages of those weights to the chain, rather than calculating weights for miners from scratch. Weights are a normalized score vector, calculated by each validator to score each miners performance.

Since all validators can choose to weight copy and ignore a subnetwork's reward mechanism entirely, there needs to be some verification that at least one validator is communicating with miners and scoring them appropriately based on the subnet owner's reward criteria.

The Yuma Consensus rewards subnet validators with dividends for producing miner-value evaluations that are in agreement with the subjective evaluations produced by other subnet validators, weighted by stake.
- Bittensor Documentation

The motivation behind weight copying is twofold;

Validators must maintain expensive hardware and a team of staff for operations. Weight copying validators do not need to do the work to grade and calculate scores for miners, and thus they can validate for a fraction of the cost.
In subnets with high VTRUST variance, an optimal strategy is to weight copy. Since some weight copiers use stake-weighted average weights from other validators, they calculate the exact weights Yuma Consensus will consider ideal. This increases their VTRUST higher than all other validators and as a result increases their dividends.

This practice is controversial. Key topics of concern surrounding the practice of weight copying include:

Centralization Risk. Since weight copying validators are simply looking at weights from other validators and picking average values, the validator is no longer contributing to the decentralization of the network; instead it is centralizing control over rewards to the validators it's copying from.
Amplification of errors. Since weight copiers don't need to have an idea of what's going on within the subnet beyond the weights that other validators are setting, any issues or malicious behavior exhibited by actively participating validators will be blindly copied and thus amplified. Since weight copiers do not run the validation task, they have no idea if the network or any miner is performing as expected.

In terms of Yuma Consensus, any validator that submits weights closer to a stake-weighted average of all validator weights will get the highest emissions. As long as the validator submits weights to the chain, they're accepted at face value. The weights alone are insufficient evidence of a validators work completed.

One method that has been implemented to combat this behavior is called commit-reveal. Commit reveal is a strategy which encrypts and delays decryption of validator submitted weights in an effort to lower the dividends and VTrust for weight copying validators participating in the subnet. Effectively, this means weight copiers are forced to submit old weights which have potentially diverged from consensus, while validators who query the subnet have up-to-date weights since they're adjusting weights based on realtime interactions with miners.

The solution

Proof of Weights

Proof of Weights will solve the problem of verifying that a validator completed honest scoring work through the use of zero knowledge proofs. In addition to validators committing weights on-chain, validators must prove they have run the scoring function for a subnet. The calculated weights and zk-proof are committed to the chain and fully verified. To implement Proof-of-Weights within a subnet:

Subnet owners create a reward method and convert their reward function into a verifiable zk circuit. This produces a verification key, which is later used to verify a proof, and a proving key, which is used by each validator to generate the proof of their scoring.
Subnet owners publish the model's verification key on-chain. When changes to the reward mechanism are made, the subnet owner will create a new verification key and update on-chain.
Validators submit proofs along with the weights they set on-chain.
Using the verification key published by the subnet owner, validator proofs are verified. Any proofs that fail verification result in penalties for the submitting validator.
Validator Proof of Weights are unique to them, the proof cannot be copied from another validator.

Why Proof of Weights

Proof of Weights allows validators to prove that they have completed the work required to score each miner on the subnetwork. When a scoring change is made, an accompanying zero knowledge proof is generated, allowing for trustless verification that the correct scoring function was run and that the inputs and outputs reported were the same inputs and outputs run through the scoring function. Validators who cannot provide this proof will be slashed according to the subnet owner's desired weight copier penalty.

By including the validator's public key as an input feature in the reward mechanism, each validator is forced to provide a unique proof, thereby preventing proof copying. By verifying proofs generated by validators, the work the validator did is verified and cannot be forged or copied from any other validator.

Proof of weights operates in a different manner compared to commit-reveal. It allows the ability for validators within a subnet to prove that they are not weight copying, which can even help to improve weight copying by allowing weight copiers to avoid copying from other weight copying validators within a subnet. Proof of weights provides certainty that a given validator is participating in the network and is providing weights that align with the intended scoring functionality of the subnet.

An implementation of our proposed solution to weight verification includes optional changes to validator software and required changes to the Bittensor blockchain as outlined below.

Technical Overview

To enable proof of weights on a subnet, the subnet owner first needs to convert their incentive mechanism into a zero knowledge circuit, and post the verification key on-chain so proofs generated by validators can be verified when determining consensus.

First, subnet owners define their incentive mechanism as a PyTorch module. This allows the subnet owner to define any and all inputs and outputs they want to be included in the proof as well as the calculations to be proven. An example of this can be found in Subnet 2's reward function. The subnet owner must then convert their incentive mechanism into an ONNX representation, which prepares the operations conducted within the mechanism for conversion into a zero knowledge circuit.

Inference Labs is developing an SDK to allow subnet owners to easily convert their incentive mechanisms into optimized zero knowledge circuits, avoiding the need to manually convert the mechanism into ONNX and perform circuitization.

Next, the subnet owner creates a zero knowledge circuit representing their incentive mechanism, based on the previously generated ONNX graph. Tools to circuitize include Circom and EZKL. After creating a Halo2 circuit for their incentive mechanism, the owner is provided a proving key and verification key along with a base circuit file. These files are the core components of the proven function and used in the following steps by a variety of parties.

The subnet owner must then provide their generated verification key to the blockchain as a hyperparameter, defining the key which the base blockchain validators will use for verification, when weights are submitted by validators participating in the subnet. The subnet owner also needs to distribute the proving key and circuit files to the desired proving network. Omron is recommended as a proving network due to it's incentive mechanism directly promoting fast and accurate proof completions by miners within the proving cluster. This unqiuely optimizes Omron for the task of efficiently proving at scale.

Once the proving key is distributed to the desired prover entities, and the verification key has been committed on-chain, the subnet owner will need to set their desired weight copying penalty as a hyperparameter to set the amount of dividends and trust they intend to remove from validators that cannot provide a valid proof with the weight they set. Essentially penalizing validators who cannot show their work.

Once implemented, validators will update scores locally by performing inferences through the circuit. These inferences through the circuit do not provide proofs but instead provide a witness file, which provers can attest to at proof-time. This witness file contains both the validator's inputs to the function along with any outputs as defined by the subnet owner, the miner's updated score being one of these outputs. The score is then used by the validator, who continues to complete N number of queries to miners during their weight setting interval. At the end of the interval, when the validator will set it's weight on-chain, the validator bundles it's witness values and submits them to a prover, who provides cryptographic proof of the validator's scoring changes based on the subnet's incentive mechanism, the inputs provided and the output scoring changes.

Once received, the proof along with normalized weight vectors are verified by blockchain validators. When a proof is verified, the inputs, outputs and underlying circuit are successfully attested to, providing hard proof that the values generated were done so correctly.

At the blockchain layer, two new subnet hyper-parameters are proposed:

proofOfWeightPenalty / setProofOfWeightPenalty - The amount of penalty to apply to validators who fail to provide a proof along with the weights they set.
proofOfWeightVK / setProofOfWeightVK - The verification key used to verify validator's scoring functions

When validators set weights on chain and a Proof of Weights penalty amount is enabled by the subnet owner, yuma consensus verifies the proof submitted along with validator's weights, using the verification keys provided by the subnet owner. Validators that do not submit valid proofs will receive decreased Vtrust and therefore dividends based on the defined penalty.

Analysis

To analyze the impact of proof of weights upon validators that supply invalid weights such as copiers, we simulate tempos with regular weight fluctuations, using a modified yuma consensus which includes a weight copy penalty applied to validators that fail to supply a valid proof. The weight copy penalty is designed to be a subnet-configurable hyperparameter which allows subnet owners to slash those who fail to produce a valid proof accompanying their weights by a desired percentage. In the below depiction, we use median dividend values for non-copying validators, and dividend values from a single consensus copier. As shown, without a penalty, the copier has a significant advantage in terms of dividend and VTrust due to it's adherence to consensus weights. When a penalty of 0.4 (or 40%) is applied, however, the validator supplying invalid proofs loses a significant portion of their dividends. This results in the validator supplying invalid proofs being disincentivized entirely from validating - the validator would earn more by delegating their stake to a validator that is supplying valid proofs to the chain.