如何运行验证者：自用，还是对外做服务

「不要信任，去验证」这句话，只有在你能亲自跑起验证者的时候才算数。在 TensorCash 上你可以：验证者是开源的，矿工产出的证明是自包含的，而把检查它的那套东西搭起来，是一件有文档、可复现的活儿。

有一个选择会牵动后面所有事，先把它定下来。

两条路：自用，还是对外做服务

两种跑法用的是同一套开源引擎，区别只在于它替谁回答问题。

	自用	对外做服务
服务对象	你自己 —— 你的节点、你的证明	同时服务很多调用方
图什么	「模型确实跑过」不必信任任何人	「算一次，服务多方」
形态	引擎和你的节点部署在一起	引擎放在 HTTP 网关后面
覆盖范围	一台机器，朝内	矿工、节点、区块浏览器、其他验证方

自用是主权式的自查：每一个区块证明 —— 或者某个不是你自己产出的证明 —— 都在你自己的机器上重新检查一遍，AI 到底有没有真的执行，不依赖任何第三方。对外做服务则把同一套引擎朝外：在 HTTP 网关后面，你运营的这一台验证者，为所有指向它的人回答「活儿有没有跑过？跑的是哪个模型？」。

挑你需要的那一半看，下面两边都会讲。

验证者到底检查什么

验证者是一串由便宜到贵的检查，一级一级往上走，最后落到 GREEN / AMBER / RED 三种结论之一：

quick 和 quick-smell —— 快速的结构筛查和统计筛查，跑在 CPU 上。
pow —— 对推理输出做的工作量证明。
model —— 在 GPU 上把声称使用的模型重跑一遍，检查重放出来的 logits 是否对得上，以及实测的模型算力是否和声称的难度一致。这就是对「跑的是哪个模型」的断言。
full —— 完整检查；logits 则把原始的重放结果直接暴露出来。

所以一个结论回答的，是链上其余一切所依赖的两个问题：活儿到底跑没跑，以及产出它的是哪个模型。（模型本身的批准由运营方把关 —— 一次 model 检查可能落到待审核状态，需要人工批准或驳回，之后才会被信任。）

自用怎么跑

主权式部署把开源验证者引擎和你的节点放在一起，你的节点接受的每一个区块，都会在你自己的机器上重新检查一遍 —— 中间没有第三方。core-validation-api 这套编排正是这个拓扑：节点 + 你自己的验证者 + 一个本地网关，不含矿工。full/model 的重跑发生在你自己的硬件上，所以需要一块 GPU 和模型本体，还需要一个 OPERATOR_API_KEY（没有它 compose 起不来），以及给节点到网关的调用做鉴权的 VERIFY_SHARED_API_KEY。链和裁剪的配置来自你挂到数据目录下的 bitcoin.conf；core-node 镜像里的挖矿 supervisor 还得靠一个 compose override 才能关掉 —— 所以想干净地把它拉起来，得照着仓库来，具体见如何运行节点。

如果你只想把引擎单独架起来验证证明 —— 不挂节点 —— 那就直接从源码跑，下一节讲的就是这个。如果同一台机器上你还想挖矿，完全主权的那套编排 core-miner-validation-api 会再加上 worker —— 也就是如何挖矿里那个挖矿主权开关的另一头。

**检查一个不是你自己产出的证明。**引擎把整条验证阶梯通过 HTTP 暴露出来。证明是一个二进制 FlatBuffer；/json 那几个接口接受 base64 编码后的 proof_b64 字段（也有直接收 application/octet-stream 的原始接口）。提交，然后读结论 —— 或者按 id 查某个证明：

# Base64-encode the proof blob and submit it to the full check:
PROOF_B64=$(base64 -i proof.bin)
curl -s http://127.0.0.1:9000/v1/verify/full/json \
  -H "Content-Type: application/json" \
  -d "{\"proof_b64\": \"$PROOF_B64\"}"

# Poll an async submission, or read a proof's status by id. The public endpoint
# is cache-backed (no durable store in the OSS build), so it answers for proofs
# this instance has recently seen — others come back as "NAN":
curl -s http://127.0.0.1:9000/v1/verify/status/<hash_id>
curl -s http://127.0.0.1:9000/v1/public/status/<hash_id>

有意思的是 RED 这个结论：伪造的证明就是被它挡下来的 —— 不干活直接磨出一个结果，或者偷换成另一个模型。网络会不会拒绝这些，你不用听谁说；你可以亲眼看着自己的验证者把它们拒掉。

对外做服务怎么跑

朝外的时候，同一套引擎坐在 HTTP 网关后面，为很多调用方回答问题。开源的参考网关负责把 HTTP 桥接到引擎：

# Both processes use local imports, so run them from the service's src/ dir.
cd services/verification-api/src

# The engine (ZMQ in, verdict out). Quick checks run CPU-only; model/full need a GPU.
python main.py

# The HTTP gateway in front of it (bridges HTTP → the engine's ZMQ).
uvicorn extapi_stub.app:create_app --factory --host 0.0.0.0 --port 9000

在 Docker 里，core-validation-api 这套编排把引擎和一个 verification-http-gateway 接在一起。生产环境另有一个加固过的网关（gateway/verification-service），额外提供缓存与请求合并、令牌桶限流、API-key + JWT 鉴权、请求签名，以及 Prometheus 指标。

它要回答问题，需要什么：

Quick / quick-smell：只吃 CPU —— 拿来做便宜的前置筛查很合适。
Model / full：需要一块 GPU，并且模型权重要加载进来（这套编排会把已注册的模型拉进挂载卷里）。重跑前向传播的算力就花在这儿。
值得知道的几个配置：VERIFY_AUTH_ENABLED、VERIFY_API_KEYS 和 VERIFY_RATE_LIMIT_PER_MIN 负责放行和计量调用方；健康检查在 /health 和 /v1/verify/health。

一个实例能服务哪些人

「对外做服务」值得做的原因就在这里：一台验证者可以同时回答好几类调用方。一个跑起来的实例可以服务 ——

**把验证委托出去的矿工。**自己不跑验证者的矿工，把 VALIDATOR_BASE_URL（外加 VALIDATOR_API_KEY）指向你，由你来检查它的证明。
**把验证委托出去的全节点。**通过 HTTP 指向你的服务的全节点（VALIDATOR_BASE_URL），把 full/model 这一步交给你，不在本地跑 —— 其余的它仍然全部自己验证，只有这一项断言信你。
**其他验证方（算一次，服务多方）。**异步的 /v1/verify/*/request 接口按证明 id 缓存结果，所以你算过一次的结论，可以直接给到后面所有来问同一个证明的人。
**区块浏览器和公开查询。**任何人 —— 一个区块浏览器，或者一个想看自己那份 share 的矿工 —— 都可以用公开、免鉴权的 GET /v1/public/status/{hash_id} 读到某个证明的结论。
**运营方。**另有一个独立的审核界面，让运营方对落到待审核状态的 model 检查做批准或驳回。

对外做服务，请负责任地做：它是一种便利，但对所有委托给它的人来说，它也把信任集中了起来。自用那条路存在的意义正在于此 —— 委托过来的矿工或节点，随时可以不再信任你的服务，改成自己跑验证者。用的是同一套开源引擎，没有新东西要学；不过活儿是实打实的 —— 他们得在自己的硬件上（GPU + 模型）把引擎架起来，再让节点指向它，流程见如何运行节点。

挖矿的另一头

如果你读过如何挖矿，这篇讲的就是那个主权开关另一端的东西。一个把验证委托出去的矿工，把 VALIDATOR_BASE_URL 指向某处，等于是在说「我的证明由别人来检查」。**跑验证即服务的人，就是这个「别人」。**挖矿和验证是同一条流水线的两端；跑验证者，就是在选自己站哪一端。

接下来看什么

开源验证者 API —— 全部接口：/docs/verifier/api/
证明与 FlatBuffers schema —— /docs/schemas/
跑一个节点来对着验证 —— 如何运行节点
在同样的证明上挖矿 —— 如何挖矿
为什么造假很贵 —— 验证白皮书

验证者不会因为我们说了什么就信什么。自己跑一台 —— 自用也好，服务一群人也好 —— 你也就不必信我们的话了。

本文由 Imosuke Takakuni 以化名撰写。