0x9a.com

保持简单,保持好奇

基于 PoW 的防作弊 GPU 排行榜

2026-04-16

做 GPU 排行榜,最容易想到的方案是:本地跑一次 benchmark,然后把分数上传。

问题是,只要榜单公开、分数有比较价值,作弊几乎一定会出现。因为在这个模型里,客户端既是运动员,也是裁判:它既负责计算结果,也负责上报结果。只要上报链路可控,伪造成绩的门槛就不高。

我后来把这个问题换了个思路:不让客户端“报分”,而让客户端“交证明”。这就是 PoW 在排行榜场景里的价值。

先说清楚:什么是 PoW?

PoW(Proof of Work,工作量证明)可以理解为一种“先做题,再交卷”的机制。

给定一段输入(challenge),你要找到一个 nonce,使得哈希结果满足某个难度条件,例如:

可以写成:

hash(challenge || nonce) < target

PoW 有两个关键特性:

  1. 求解难:不知道答案时,通常只能大量尝试。
  2. 验证易:拿到 nonce 后,服务端算一次哈希就能判断真伪。

这正好适合“防伪造成绩”的需求:你可以伪造一个数字,但很难伪造一批真实可验的解。

基于 PoW 的典型应用

PoW 并不只属于加密货币,它在很多“需要低成本验证工作量”的场景都很实用。

1. 区块链(最经典)

以比特币为代表的 PoW 区块链里,矿工要持续尝试 nonce,找到满足难度目标的区块哈希,才能获得出块资格。

它的核心价值是:

简单说,区块链用 PoW 解决的是“在不互相信任的开放网络里,谁有资格写入下一块数据”。

2. 防机器人验证码(Cap.js)

Cap.js 这类现代 CAPTCHA,也在用 PoW 做防滥用。

根据其文档,Cap.js 的思路是:

这类方案的目标不是“让人类看图识字”,而是“让批量自动化请求付出可观计算成本”,从而抬高攻击方的经济开销。

为什么 PoW 适合 GPU 排行榜

把 PoW 用在 GPU 排行榜里,有几个天然优势:

于是排行榜的核心从“谁报的分数更高”变成“谁提交了更多、且可验证的有效工作量”。

从“自报分数”到“可验证成绩”

这类排行榜可以用一条更可信的流程:

  1. 服务端签发一次性 challenge/session。
  2. 客户端在本地 GPU 上求解,得到一组 nonce。
  3. 客户端提交的不是 benchmark 分数,而是 nonce 列表。
  4. 服务端逐个验证 nonce 的有效性。
  5. 最终分数由服务端按“已验证工作量 / 服务端观测耗时”计算。

一个常见写法是:

effective_hashrate = verified_work / server_elapsed_time

这里最重要的是:计时和计分都由服务端主导,客户端只负责“算”和“交证明”。

反作弊真正依赖的是“约束组合”

PoW 本身很重要,但真正提高可信度的是围绕它的一组约束:

这些约束叠加后,系统不再追求“完全不可作弊”,而是把作弊成本抬高到远高于正常参与成本。

排行榜展示也会影响可用性

除了“怎么算分”,还要考虑“怎么展示分数”。

一个更实用的策略是:

这样榜单更接近“型号对型号”的比较,不会被同型号的大量相近成绩淹没。

边界:PoW 不是银弹

需要强调的是,PoW 方案并不能保证绝对公平。

开放客户端环境里,始终存在脚本自动化、设备信息伪装、驱动差异、平台抖动等现实问题。PoW 的意义不在于“彻底杜绝作弊”,而在于把排行榜从“几乎无法验证”推进到“可验证、可审计、可持续运营”。

这已经是一个很大的改进。

回到我的实践:nierf.com

最后还是回到这个问题本身:我做的 nierf.com GPU 排行榜,核心目标并不是“做一个更炫的跑分页面”,而是尽量让榜单结果更可验证。

对应到实现思路,就是把“提交分数”改成“提交 PoW 解”,再由服务端统一验算和计分。这样至少能避免最直接、最廉价的伪造成绩方式,让排行榜更接近真实算力表现。

结语

GPU 排行榜最难的从来不是跑分本身,而是让公开榜单尽量保持参考价值。

把机制从“客户端自报分数”改成“客户端提交 PoW 解、服务端验算计分”,本质上是在重建信任边界:

PoW 不是银弹,但它确实是一条务实、可落地的防作弊路线。

← 返回首页