Proof-of-Compute (PoC): The Engine of Useful Work
Proof-of-Compute is SuperNet's novel mechanism for integrating high-value, intensive AI computation directly into the block production process. It redefines traditional Proof-of-Work by replacing wasteful, arbitrary hashing with the useful work required to power the network's core services.
Mechanism: In the PoC model, validators utilize specialized hardware (e.g., GPUs/TPUs) to compete to execute batches of computational tasks aggregated from the network's transaction pool. These tasks are primarily the execution of vector similarity searches (e.g., kNN queries) and the construction of on-chain context graphs.
Function: PoC’s function is to convert the network's computational requirements into its consensus engine. Validators may assign compute tasks to compute providers, compute providers need to stake enough super token for eligibility and earn emission from finishing computing tasks of the network. This tightly couples the network's utility with its security; the very act of performing useful work for applications is what drives the blockchain forward.
Verification: The integrity of the off-chain work performed by Computation Providers is paramount. Rather than relying on costly full re-execution, Supernet secures the Proof-of-Compute through Merkle proofs. This ensures that while intensive computation occurs off-chain, its results can be trustlessly and economically verified on-chain.
The process is as follows:
Proof Generation: After a Computation Provider (CP) executes a batch of tasks, it uses the compute results to construct a Merkle tree. The final output submitted on-chain as the "proof of work" is the single Merkle root of this tree. This root acts as a compact, deterministic, and tamper-proof fingerprint representing the entire batch of completed work.
On-Chain Verification: The Proof-of-Stake validators, responsible for securing the network, do not need to re-compute to verify the CP's work. Instead, they perform a rapid and lightweight "spot check." The verification protocol can deterministically select one or more random tasks from the original batch for the validator to re-compute locally.
The Challenge-Response: The validator then challenges the CP to provide the Merkle inclusion proof for the specific result(s) it spot-checked. This inclusion proof consists of the result's hash and the small set of sibling hashes required to reconstruct the path up to the submitted Merkle root.
Validation and Slashing: The validator uses the result it computed locally and the provided inclusion proof from the CP to calculate the root hash. If this calculated root matches the Merkle root originally submitted by the CP, the proof is considered valid. If there is a mismatch, the proof is invalid, demonstrating that the CP's work was fraudulent. This failure immediately triggers a protocol-level action to slash the CP's staked $SUPER.
Last updated