Full Node

假设钱包显示收到一笔付款。它怎么知道这笔交易真的属于 Bitcoin 历史，而且符合规则？钱包可以询问外部服务器，也可以使用你的节点。Full Node 让第二种选择成为现实：它根据收到的数据独立判断有效性，不会询问多数已连接计算机应该如何决定。别人发来违反规则的区块，它就拒绝。因此，连接数量不能代替规则检查。自己的节点让你能够亲自验证付款所依据的数据。 [1] [3]

节点检查区块之间的连接、区块头和 Proof of Work，也就是区块必须具备的计算证明。对交易，它会检查引用的资金是否存在、是否被重复花费，以及使用条件是否满足。这些条件写在脚本中，即小型程序规则。节点也检查新创建比特币的数量。持续更新的结果是 UTXO set，也就是尚未花费的交易输出集合，记录具体哪些资金仍可使用。较大的累计工作量可以决定两条有效分支之间的选择，却不能让无效区块变成有效。 [1]

不是。Full Node 验证区块和交易，仅进行普通验证不会获得区块奖励。矿工则组装新区块提案，反复计算，直到找到满足条件的结果。这项计算使用 hash，也就是区块头的数字指纹。两种角色可以相互配合：矿工需要知道正在延续哪段历史，以及哪些交易可以纳入。但这不意味着每个节点都要挖矿。验证与争取找到下一个区块，是不同的活动。 [5] [1]

新节点首先要追上网络历史。它下载区块并处理数据，这叫初始同步。高级设置中有两种加速方式，需要区分。在规定条件下，Bitcoin Core 的 assumevalid 可以跳过旧脚本检查；assumevalid=0 会关闭这项优化。AssumeUTXO 则允许加载状态快照，也叫 snapshot：某个区块时点保存的未花费资金状态。程序会把其指纹与源代码中包含的值进行比较，随后在后台验证更早的历史。因此，当前状态已经可用，并不代表历史检查已经完成。 [1] [2]

Full Node 不必永久保存全部旧区块文件。Pruning 会在处理后删除一部分文件，同时保留当前 UTXO set 和必要的较新数据。节点仍然继续验证新区块。归档节点保留旧区块，因此能提供给其他节点，或再次扫描。节省磁盘并不等于变成 SPV 客户端，即采用简化支付验证的客户端。后者不会像 Full Node 一样检查所有交易及其状态。区别在于验证什么，而不只是保存了多少文件。 [3]

普通同步时，剪枝节点先下载并处理历史区块，然后才逐步删除。因此，Pruning 不是跳过旧区块验证的开关，而是节省存储空间的办法。前面介绍的优化是另一个问题：assumevalid 在一定条件下跳过旧脚本检查，AssumeUTXO 则允许在历史验证尚未完成时先使用快照。判断节点是否就绪，需要同时查看同步方式和实际进度，而不能只看磁盘上的数据大小。 [3] [2]

钱包需要交易和确认信息。如果从外部服务器获取，就会向它发送查询，服务器可能由此推断钱包的部分付款情况。连接自己的 Full Node，可以使用经过该节点验证的数据，避免向外部服务器发出这些查询。但是，仅仅安装和启动节点，不会自动改变钱包的连接。关键是钱包实际支持并使用什么数据来源。自己的节点也不会自动带来匿名性：隐私还取决于其他网络信息和使用钱包的方式。 [3] [4]

节点可以在没有你的私钥的情况下运行。密钥用于签署付款；节点检查交易和区块是否符合规则，这两项工作不必由同一设备承担。因此，除了确认自己的节点确实在运行，还要检查钱包从哪里读取数据、通过什么途径广播交易。独立验证不能替代安全的密钥备份，也不能消除网络通信可能暴露的所有信息。它解决的是流程中的具体一环：独立检查 Bitcoin 数据。 [3] [4]

节点有两种不同接口。P2P 连接用于与其他节点交换区块和交易；RPC 则供应用发送命令，某些情况下也能控制节点的钱包。因此，开放入站 P2P 端口交换数据，与把 RPC 暴露给陌生人完全不同。Bitcoin Core 建议不要把 RPC 直接暴露到公共互联网。本地访问通常使用 .cookie 文件中的登录凭据，以确认应用具有权限。这不是浏览器的跟踪 cookie。 [4]

节点命令能提供比绿色图标更多的信息。在 getblockchaininfo 中，应检查网络是否正确，blocks 表示已处理区块数量，headers 表示已知区块头数量，initialblockdownload 表示初始同步状态。使用快照时，getchainstates 有助于区分当前状态和后台历史验证。连接数量本身不能证明验证完整。最后，还要确认节点没有停留在过时的链顶，并且钱包确实从它获取数据。这样，节点的独立验证才真正服务于你的钱包使用。 [2] [1]