如何运行节点：在自己的机器上把整条链验一遍

跑一个全节点，是你在链上能做的最诚实的一件事：不用去问某台服务器发生了什么，你的机器按规则自己重新推一遍。多数网络里，这些规则就是签名和工作量证明。TensorCash 还多一条——区块的工作量证明本身就是一次真实的前向传播，所以全节点还要检查 AI 模型确实跑过。

这篇就是动手跑节点的指南。第一件要定下来的事不是硬件，也不是命令——而是最后这条规则，你信谁来查。

第一个决定：谁来验证 AI？

每个区块都带着一份证明：某个经链上批准的模型，产出了某个特定的输出。节点必须先认定这份证明有效，区块才算数。这一步检查有两种做法。

	自建验证者	委托出去
full/model 重跑由谁做	你自己，用你自己的硬件（GPU + 模型）	你指定的第三方
你需要信任别人的部分	没有	只有「AI 确实执行过」这一条
两种做法都在本地检查的	签名、工作量证明、结构、模型注册表、VDF 证明，以及快速的 quick/smell 初筛	同左

有两点要说准确。第一，便宜的检查节点永远自己做——签名、工作量证明、模型注册表，还有对推理证明的一次快速 quick/smell 初筛，全部在进程内完成。这个选择挪动的是昂贵的那部分：真正重新执行一遍前向传播（也就是 full 和 model 两项检查），确认注册的那个模型确实产出了那个输出——而这次重跑需要 GPU 和模型权重。

所以，自建验证者意味着「模型跑过」这件事你谁也不用信，代价是得自备硬件；委托则是节点把 full/model 检查交给你选定的验证者，并在这一条上采信它的结论。

第二点常有人栽跟头：验证者由谁运行和节点怎么连上它是两回事。传输层要么是本地 ZMQ 套接字（-validationapi=real；启动脚本里的 --desktop），要么是 HTTP（-validationapi=desktop，或环境变量 VALIDATOR_BASE_URL）。HTTP 照样可以指向你自己机器上的验证者（比如一个本地网关），所以走 HTTP 并不等于委托。决定主权的是谁在运行验证者，不是传输方式。

验证者引擎本身怎么跑——自用也好，作为服务给别人委托也好——是另一篇实操指南，见如何运行验证者。这里我们只把节点接到它上面。

第一步：选网络

先从测试网开始。节点用 -chain（或者更省事的别名）来选链：

网络	参数	RPC 端口
测试网（从这里开始）	`-tensortest`（`-chain=tensor-test`）	29240
主网（需协调）	`-tensor`（`-chain=tensor`）	39242
本地私链	`-regtest`	18443

用 Docker 部署时，选哪条链写在节点的 bitcoin.conf 里（挂载到数据目录），不在命令行上——仓库提供的测试网 stack 自带一份现成的 bitcoin.tensor-test.conf，还有 run_tensor_testnet.sh 帮你把它放到位。主网的挖矿和验证需要协调——先从测试网开始，先在那儿把自己的节点跑起来。

如果你想要一条用完就扔、从头到尾归你控制的本地链——挖个区块、注册个模型、看它确认——regtest 快速上手是最快的一圈，而且完全不碰公网。

第二步：修剪还是归档？

节点要存链。存多少留在磁盘上，由你决定。

归档（-prune=0，默认）： 所有区块永久保留。想要交易索引（-txindex），或者打算给其他节点提供历史区块，就得这么跑。
修剪（-prune=N）： 磁盘上只保留最近一段窗口内的区块，上限 N MiB。下限是 550 MiB。-prune=550 是能用的最小设置；-prune=2000 留的窗口宽裕些。

修剪在这里是一等公民，正式支持——只有一点要搞清楚：它动什么，不动什么。

修剪删掉的是： 只有旧的区块文件和 undo 文件。这是链上最占地方的部分，而且修剪节点当初经过这些区块时，每一个都完整验证过。

修剪从不碰的是：

chainstate（当前的 UTXO 集合），
资产注册表（它存在 chainstate 里，不在区块文件里），以及
ModelDB——记录哪些模型已注册、哪些在生效的索引，它有自己独立的数据库，配一份 undo 日志，逐个区块往前推进。

所以修剪节点照样能完整回答「这个模型批准了吗？」和「这个资产是什么？」。你放弃的是对外提供旧区块体；共识检查一项都没少。

唯一值得记住的注意事项。 遇到非正常关机，ModelDB 一般靠回退自己的 undo 日志就能恢复——不需要历史区块，所以在修剪节点上是安全的。真正需要旧区块的操作只有一种：ModelDB 从创世块全量重建。在修剪过的数据目录上，节点会直接拒绝，而不是建出一个损坏的索引——退出时会给出明确提示。真碰上了，办法是做一次完整的 -reindex（它会重新下载区块）、清库重同步，或者恢复一份 ModelDB 快照。实用原则：修剪的机器上永远别去碰 -reindex-chainstate（它本来也和修剪不兼容）——非要重建就用完整的 -reindex。

第三步：跑起来

源码编译（bitcoind）

如果你从源码编译过，上面每个选择都对应一个普通参数——这是控制节点最直接的方式。验证后端由 -validationapi 决定。

本地验证用 -validationapi=real（默认值）：full/model 检查走本地 ZMQ 套接字，因此需要有一个验证者引擎在跑，而且连得上（见如何运行验证者）：

bitcoind \
  -tensortest \
  -prune=550 \
  -validationapi=real \
  -rpcuser=user1 -rpcpassword=change-me \
  -daemon

委托 full/model 检查走 HTTPS，用 -validationapi=desktop——quick/smell 仍留在本地，full/model 发给你指定的验证者。这是轻量路线：本机不需要 GPU。

bitcoind -tensortest -prune=550 \
  -validationapi=desktop \
  -validatorhttpurl=https://verify.example.org \
  -validatorapikey=change-me \
  -daemon
# Replace verify.example.org with your verifier's URL.

（修剪和 -txindex 不兼容。要完整的交易索引，就跑归档。）

Docker（仓库自带的 stack）

仓库里的 docker-compose stack 是运维工具，不是一行命令的快速上手：它们会把节点和验证者（完整版里还有矿工）一起拉起来，因此默认你有 GPU 和模型。上手之前有几点要知道：

选链和修剪写在 bitcoin.conf 里，挂载到数据目录，不在 compose 命令上。测试网 stack 自带 bitcoin.tensor-test.conf（只有选链和端口），以及 run_tensor_testnet.sh 帮你把它放进数据目录——但它没有设置任何修剪，想要修剪节点就自己往那份 conf 里加一行 prune=550。
OPERATOR_API_KEY 是必填的——不给它 compose 起不来——验证者那边认的是 VERIFY_SHARED_API_KEY（直接设 VALIDATOR_API_KEY 不起作用，compose 会自己推导）。
core-node 镜像会自动拉起一个挖矿 supervisor。 它由 MINING_AUTOSTART 环境变量控制，而基础 compose 文件并没有把这个变量暴露出来，所以要让它闭嘴得写一份 compose override，光设 shell 变量没用——想要一个完全不碰挖矿的节点，就得准备改这套 stack。

正因如此，只要一个普通节点，上面的源码路线更简单，也能直接复制粘贴——尤其是走委托的轻量节点，连 GPU 都不用。只有当你确实想要这套打包好的拓扑时，再去用 compose stack（deployments/docker-compose/core-validation-api/ 是节点 + 自建验证者，core-miner-validation-api/ 是节点 + 验证者 + 矿工）；后者附带的 run_tensor_testnet.sh 是正式支持的测试网 stack 启动方式。

第四步：同步好了吗？验证跑起来了吗？

三项检查，按顺序来：

# 1. The chain is catching up to the tip.
bitcoin-cli -tensortest getblockchaininfo | grep -E 'blocks|headers|pruned|size_on_disk'

# 2. ModelDB is tracking the chain — a model query answers.
bitcoin-cli -tensortest getmodelslist                  # registered models (hash + name)
bitcoin-cli -tensortest getmodelinfo <model_hash>      # one model's full record

# 3. The verifier is wired. In the node's debug log you'll see either the local
#    verifier starting, or the node reaching the delegated endpoint.
bitcoin-cli -tensortest -getinfo            # or: tail the debug.log / `docker compose logs -f`

blocks 追上 headers，就说明你已经到链尖了。从那一刻起，你的节点接受的每个新区块，签名、工作量证明、以及模型执行证明都查过了——如果你选的是本地验证，那就是你自己查的。

把节点用起来

同步完成的节点，就是一个货真价实的 Bitcoin 风格 RPC 端点，外加 TensorCash 自己的那些接口：

钱包与资产——createwallet、getnewaddress，以及资产类 RPC（mintasset、sendasset）。在同一个节点上跑桌面图形界面是另一篇实操指南：如何运行钱包。
对着自己的节点挖矿——自主矿工从你的节点领任务，而不是某个服务商的 broker，并且在你的验证者上验证。这就是如何挖矿里那条「完全自主」路线：WORKER_MODE=standalone 指向这个节点，检查交给 --desktop。

接下来看什么

从头到尾在本地跑一遍——regtest 指南：/docs/regtest/
核心节点 API / RPC——/docs/core-node/api/ · /docs/rpc/
自建验证者——如何运行验证者
桌面钱包——如何运行钱包
模型检查为什么可靠——验证白皮书

这里的全节点会查一件别处的节点查不了的事：区块背后的那份工作是真的。

本文由 Imosuke Takakuni 以化名撰写。