与以太坊的每次交互都要通过一个节点，而且并非所有节点都是相同的。有些只存储最新的几百个区块，另一些则保留自创世以来的每个状态。有些客户端返回丰富的追踪信息，另一些则默默地丢弃不支持的 RPC。了解你使用的是哪种节点和客户端可以节省数小时的调试和困惑。
在这篇文章中，我们将剖析以太坊节点是如何实际运作的，从 Full、Archive 和 Light 节点到主要的 execution clients，如 Geth、Nethermind、Erigon 和 Besu。你将看到它们的数据保留、同步方法和 RPC 实现如何影响你调试、追踪和重放交易的能力。
最后，我们将看看什么时候 运行你自己的节点 比依赖共享 RPC 提供商更有意义，它的实际成本是多少，以及如何决定哪些值得自己托管。
节点类型
在我们讨论 eth_call 和 debug_traceCall 之前，我们需要解决下一个问题：你连接的是哪种类型的节点？
你使用的以太坊节点类型决定了 哪些数据可用 以及 当你模拟或追踪交易时可以追溯到多远。选择错误的节点可能会导致令人困惑的“缺少状态”错误或不完整的追踪。
Full Node
一个完整节点存储 所有区块头和区块体 以及 足够的最近状态数据，以验证区块链并为链的最新部分提供查询服务。
它 不 存储每个区块的完整历史状态，只存储最近的一小部分。通常是最近的 128 个区块 左右。较旧的中间状态会被修剪以节省资源。
完整节点 一次验证一个区块 的区块链，下载并检查区块的交易及其相应的状态更改。
它们的同步方式有所不同：有些从 创世区块 开始，验证历史中的每个区块，而另一些（如 Geth 的 snap sync）则从更近的、受信任的检查点开始，并从那里向前推进。
无论采用哪种同步方法，完整节点都只保留 最新状态的本地副本。任何较旧的数据都会被删除以节省磁盘空间。这并不意味着数据永远消失了。如果需要，节点可以通过重放早期区块的交易来重建较旧的状态，尽管这比直接从存储中读取要慢。
历史访问：
- 可以处理最近区块的查询，但无法检索较旧区块的帐户/存储状态，除非重建它。
典型用例：
- 维护区块链数据的完整副本，但定期修剪较旧的状态，因此它不会保留一直到创世的每个状态条目。
- 通过检查每个区块及其相关的状态转换，积极参与验证链。
- 可以直接从其本地存储或通过从存储的快照重建来提供任何状态数据。
- 通过响应请求并与其他节点共享数据来为点对点网络做出贡献。
注意：
如果你尝试对几个月或几年前的区块进行 eth_call 或 debug_traceCall，完整节点很可能会失败，因为该状态早已被修剪掉。
Archive Node
一个存档节点包含完整节点拥有的所有内容，外加 自创世以来每个区块的完整历史状态记录。这意味着它会保留每个帐户余额、合约存储值和状态树，就像它们在任何时间点一样，而无需修剪。
当你查询存档节点在区块 5,000,000 的状态时，它可以立即返回数据，而无需从较早的区块重建它。这使其成为需要精确历史数据的开发人员和服务的理想选择。
典型用途：
- 提供对历史余额、合约存储和历史上任何区块的状态的 即时访问。
- 支持对任何过去的区块进行详细的交易追踪 (
debug_traceCall)，而无需额外的计算。
- 为区块浏览器、分析平台、历史研究和需要深入历史数据的 dApp 提供支持。
权衡：
运行存档节点比完整节点需要 显著更多的存储和资源。因此，许多团队依赖于 RPC 提供商，他们付费提供存档访问，而不是自己托管。
Light Node
轻节点只存储 区块头，并依赖完整节点或存档节点来获取它需要的任何额外数据。它使用区块头中包含的加密证明来验证数据，使其能够在不持有完整链的情况下确认正确性。
这使得轻节点非常节省资源，它们可以在存储或带宽有限的设备上运行，但这也意味着它们在大多数查询中 依赖 其他节点。
典型用途：
- 在钱包、移动应用程序或嵌入式设备中运行，这些设备的存储和 CPU 能力有限。
- 验证交易和区块头，而无需下载整个链。
- 快速与网络同步，以实现快速启动时间。
局限性：
- 无法执行
debug_traceCall，因为它不保存执行数据。
- 即使是
eth_call 也只有在连接的完整/存档节点支持请求的区块时才有可能。
- 历史查询完全取决于上游节点的功能。
不同的节点客户端，不同的行为
当你运行像 eth_ 或 debug_ 这样的 RPC 调用时，你不是在与作为单个系统的“以太坊”对话，你正在与 以太坊协议的特定实现 对话，这被称为 客户端。
以太坊有多个执行层客户端，它们都是由不同的团队用不同的编程语言构建的，并且有它们自己的设计选择。它们都遵循相同的共识规则，但它们可能在以下方面有所不同：
- 可用功能： 有些客户端支持某些
debug_ 或 trace_ RPC 方法；另一些客户端根本不实现它们。
- 输出格式： 即使两个客户端支持相同的方法，结果的 JSON 结构也可能不同。
- 性能特征： 客户端服务历史数据或生成追踪的速度取决于其数据库设计和同步模式。
- 同步方法和修剪： 客户端在从网络同步以及在本地保留哪些历史状态方面有所不同。
流行的执行层客户端
- Geth： Go Ethereum；生态系统中使用最广泛的客户端。
- Nethermind： 基于 C# 的客户端，以性能和灵活性而闻名。
- Erigon： 基于 Go，针对存档节点和快速查询进行了高度优化。
- Besu： 基于 Java 的客户端，通常用于企业和许可网络。
这些客户端在共识规则方面是可互换的，但 它们的 RPC 功能和性能有所不同，尤其是在高级调试/追踪方面。
何时你可能想要运行你自己的节点
在以下情况下，运行你自己的节点可能是正确的选择：
- 你需要 保证访问 像
debug_traceCall 这样的功能或存档历史记录，而无需依赖提供商的限制。
- 你需要高频调用的 可预测的性能（避免共享 RPC 拥塞或速率限制）。
- 你想要 完全控制 同步模式、修剪和客户端配置，以进行专门的调试或分析。
- 你需要 数据隐私（查询不会离开你的基础设施）。
成本提示：
- 一个 完整节点 通常可以在中等范围的云 VM 或专用服务器上运行，但你仍然需要支付计算、存储和带宽费用，如果托管，很容易达到 每月 50 美元到 150 美元以上。
- 一个 存档节点 是一项严肃的承诺：多 TB 存储、高 IOPS SSD 和大量 RAM。云托管的存档节点可能花费 每月 400 美元到 1,000 美元以上。
- 自行托管可以降低云成本，但会带来硬件购买、维护和电费。
