English version · 区块链学习导航 · 上一篇：更大技术体系
区块链学习 · 文章 BC007
节点是区块链网络中的参与者，通常指一个正在运行、与其他节点通信并执行规定检查或服务的软件实例。客户端是它运行的软件实现。点对点网络，则是参与节点交换信息的通信安排。
三个概念紧密相关，却分别描述参与者、程序和连接。理解它们的区别，才能解释为什么钱包无法访问时网络可能仍在运行、为什么节点不一定出块，以及为什么计算机数量不能完整衡量去中心化。
本文沿着消息和职责展开，是概念入门，不要求安装软件、开放服务器、质押资产或提供任何凭证。
选择适合你的阅读路线
本篇目录
- 1. 节点不只是计算机的另一个名字
- 2. 四项容易混淆的工作
- 3. 用图书馆转发通知作类比
- 4. 对等节点不必两两直接相连
- 5. 跟随一条虚构更新穿过网络
- 6. 内存池不是一个全球统一候车室
- 7. 比特币：完整验证与挖矿是不同角色
- 8. 以太坊：执行、共识与验证者职责
- 9. 存储标签必须结合网络与配置理解
- 10. RPC连接不自动等于轻客户端验证
- 11. 为什么界面失效时，网络可能仍在运行？
- 12. 节点数量不能统计所有独立性
- 13. 安全的纸笔练习：转发、检查与展示
- 阅读节点图时值得问的问题
- 检查你的理解
- 常见问题
- 资料来源与范围
- 学习术语：先区分节点、客户端、对等节点和运营者。
- 理解消息流动：阅读转发案例与本地交易池。
- 比较网络角色：分别阅读比特币和以太坊案例，不混用规则。
- 理解故障提示：使用后面关于钱包、区块浏览器和节点的检查问题。
1. 节点不只是计算机的另一个名字
一台物理计算机可以运行多个软件进程；一家机构可以运营许多计算机；一个人也可以使用区块链应用，而不运行完整验证节点。
为了描述清楚，应当识别软件实例及其角色，不要默认一台机器等于一个独立参与者。“这台服务器运行节点”是方便说法，但还留下许多问题。
节点跟随哪个网络？使用哪种客户端实现和版本？它验证数据、提供历史信息，还是承担特定共识职责？谁控制配置和更新？
对等节点是与它通信的另一个参与者。运营者是负责运行的人或机构。客户端是协议规则的软件实现。区分这些概念，能够避免把软件、机器与治理混画成同一个符号。
以太坊节点与客户端文档提供该网络的具体说明。其他协议可能采用不同的软件与角色划分。
2. 四项容易混淆的工作
可以先把接收、检查、保存和转发分开。
接收是从对等节点或应用接口获得消息。消息到达，不证明内容有效。
检查是应用相关协议或应用规则。具体角色可能需要检查授权、结构、执行结果，以及是否符合被接受的状态。
保存是保留运行或后续查询需要的信息。并非每个参与者都保存相同历史材料；保存更多，也不等于验证更强。
转发是按照网络规则和本地策略，把合适信息传给其他对等节点。节点不一定转发收到的每一条消息。
出块或共识投票，是某些协议中的额外角色，不应该在入门图景中默默加到所有节点身上。同一个参与者可以做多项工作，但工作仍需分别命名。
3. 用图书馆转发通知作类比
设想多家图书馆共享新增目录通知。每家与少数其他图书馆交换消息，而不是直接联系所有图书馆。一条通知可以经过多段连接，逐步被许多图书馆看到。
这个例子说明对等网络中的传播，也解释为什么同一条通知可能重复到达，以及各馆看到通知的时间可能不同。
再增加一条检查规则：只有包含必要字段、来自授权签发者的通知，才被接受。转发本身不会让通知正确，每个接收者仍需检查。
类比也有边界。真实区块链协议使用精确消息格式、密码学检查和共识规则。图书管理员凭印象觉得通知合理，不等于协议验证。
这个例子的价值，是把运输与接受分开。一条消息可以广泛传播，却仍然无效；一条有效消息，也可能未能及时送达部分参与者。
4. 对等节点不必两两直接相连
点对点网络通常不要求每个节点与所有参与者建立直接连接。信息可以经过多条链路转发。
节点需要发现可能的对等节点，并建立有用连接。引导机制帮助新参与者找到网络。但发现节点不等于信任节点：帮助建立连接的对等方，不会因此获得让无效数据变有效的权力。
连接质量很重要。一个节点即使正确检查收到的信息，如果来源有限或具有误导性，也可能形成延迟或不完整视图。通信与验证解决不同部分的问题。
比特币点对点网络指南介绍比特币的节点发现与消息交换。不能把细节全部照搬到以太坊或许可型账本，因为它们的网络安排可能不同。
学习时应问：信息怎样到达这个参与者？到达之后，它又独立检查什么？
5. 跟随一条虚构更新穿过网络
考虑一个教学网络，用于记录公开目录的变化。授权编辑者签署一条请求，增加一个虚构条目，不包含任何个人信息。
应用把请求提交到访问入口。入口可能是应用方运营的节点，也可能是另一个服务。应用不应把这一步描述为最终接受。
接收节点执行适用检查。不符合条件的请求可以被拒绝；符合条件时，节点可能把它保存为待处理请求并转发。
其他对等节点接收并检查。它们不一定同时收到，本地待处理信息可能暂时不同。
协议的排序过程考虑合适请求。转发消息本身，不是决定它最终处于已接受历史什么位置的过程。
提出的结果接受验证。承担相关验证职责的参与者，检查记录或状态是否遵守规则。
应用报告合适状态。“已提交”“某节点已看到”“已纳入区块”“按本协议达到最终性”，是不同阶段。实际阶段与保证取决于网络。
这个简化过程用于解释职责，不声称复现所有协议的完整交易路径。
6. 内存池不是一个全球统一候车室
交易池通常称为内存池，是节点本地保存待处理交易的集合，不一定是所有人同时看到的单一队列。
节点收到交易的时间可能不同，本地接纳或转发策略可能不同，资源限制可能不同，也可能尚未收到某条消息。因此，一个访问服务能看到的请求，另一个服务未必已经看到。
这解释了常见误解：“钱包显示待处理，所以所有参与者一定已经收到了。”待处理状态只能支持相关界面实际掌握的结论，不证明全网传播，也不保证最终纳入区块。
到达顺序也不一定决定最终交易顺序。出块或排序过程有自己的规则和选择。网络传播与交易排序需要分别分析。
比特币网络文档介绍交易转发；以太坊节点架构文档则说明执行客户端的交易池与网络职责。
7. 比特币：完整验证与挖矿是不同角色
比特币全节点按照规则检查区块和交易。挖矿涉及产生工作量证明区块候选。两者有关联，但运行全节点本身不等于挖矿。
当有人声称“只有出块者决定什么有效”时，这个区别很重要。正确验证的节点，不必因为区块由某个生产者提出就接受它。验证规则仍然构成系统边界。
同样，钱包使用者可能依赖另一个服务获取网络信息，而没有在本地完整验证。界面体验可以很简单，底层验证安排却可能差异很大。
比特币运行模式指南区分不同验证方式。它有助于理解角色，但部署前仍应根据当前软件文档核对实现细节。
这里要保留的概念是：检查规则、创建区块和展示钱包界面，不能互换理解。
8. 以太坊：执行、共识与验证者职责
在以太坊合并后的架构中，一个节点结合执行客户端与共识客户端功能。执行侧处理执行相关数据并检查状态变化；共识侧跟随链和共识信息。
验证者软件增加按协议提出区块、提交见证消息（attestation）等职责。节点可以跟随并验证网络，而不承担这个验证者角色。因此，“验证者”一词需要谨慎：一般的验证工作，与协议中命名的共识参与者，并非同一种描述。
以太坊节点架构指南说明这些协作组件及各自的对等网络职责。
不要把早期以太坊挖矿图，当成这套架构的完整说明。网络历史中，软件组件和职责会变化；也不要因为另一条链同样有节点，就假定它采用相同划分。
本文只解释角色，不推荐质押，也不提供参与、注资或安装操作说明。
9. 存储标签必须结合网络与配置理解
全节点、裁剪节点、归档节点和轻客户端，描述数据保留或验证的不同方面。这些术语在不同协议与客户端中并非完全统一。
根据网络和配置，验证节点可能在检查后丢弃部分历史数据。这不自动表示它停止执行规则。面向归档的服务则可能额外保留历史状态，以回答特定查询。
轻客户端使用较少数据和协议特定的验证方法。其保证取决于检查什么、取得哪些证明或共识信息，以及设计采用哪些假设。
因此，比标签更有用的问题是：保存什么数据？独立验证什么？能回答哪些问题？哪些内容必须向别人获取？
不要把旧教程中的存储数字直接用于新部署计划。磁盘需求、保留策略和客户端能力都与版本有关。本文刻意不提供通用硬件规格。
10. RPC连接不自动等于轻客户端验证
应用可以通过API向节点或服务查询。在以太坊中，JSON-RPC是查询信息和提交指令的一种常见接口。格式规定软件怎样通信，却不会单独证明返回答案正确。
钱包显示服务商提供的余额时，可能是在依赖服务商给出的结果。能够核验证明的轻客户端，则在特定设计下进行额外检查。两者对用户而言都可能很轻便，但验证性质不同。
问题不只是钱包有没有连接“区块链”，而是哪个服务提供视图、它是否检查支持证据，以及服务商返回旧信息或不可用时怎么办。
接口可参考以太坊JSON-RPC文档；不同的验证问题可参考轻客户端文档。
便捷访问有价值，但应如实描述，不应与独立验证混为一谈。
11. 为什么界面失效时，网络可能仍在运行？
假设目录应用提示“网络不可用”，可能发生了不同问题：网站故障、API服务商无法连接、选用节点落后，或底层网络确实遇到困难。
仅凭提示，不能区分这些情况。即使底层网络有很多参与者，面向用户的服务仍然可能是集中的访问入口。
区块浏览器还增加了一层。它索引和呈现信息，让读者更容易搜索。浏览器显示不等于协议本身；索引延迟或展示错误都可能影响所看到的内容。
概念性排查可以分成四问：界面能否打开？能否连接服务商？服务商是否掌握较新的视图？网络是否按规则继续推进？
这不是要求公开凭证或改变安全设置。初学者无需实际修复系统，也能理解层次。重点是避免把一条访问路径失败，直接写成“整条区块链停止了”。
12. 节点数量不能统计所有独立性
探测程序可以观察可连接节点，却不一定看到每个参与者，也未必能识别每个运营者。多个节点可能属于同一家机构，有些参与者则不会以相同方式公开可达。
以太坊节点与客户端页面明确提醒，网络追踪工具的视野有限，报告结果可能不同。
有意义的比较还应考虑客户端实现。很多独立运营者使用同一套有缺陷的软件，仍可能发生相关性故障。多个实现可以减少对单一代码库的依赖，但它们仍需遵守兼容规则并认真维护。
也不要把这简化成“客户端或节点越多，所有结果就一定越好”。多样性服务于具体目标：减少特定集中风险和共同故障。应结合实际运行与治理评估。
有用的报告会说明测量什么、何时测量，以及测量不能证明什么。
13. 安全的纸笔练习：转发、检查与展示
准备五张卡，分别写编辑者、节点A、节点B、访问服务和读者。画出编辑者到A、A到B、A到访问服务，以及访问服务向读者提供信息的连接。
给编辑者一条虚构更新，要求包含三个字段：目录编号、新标题和授权编辑标记。让A和B先检查字段，再把请求放入自己的本地待处理列表。
测试一：移除编辑标记。把卡转发给B，不应让它变得有效。这区分传播与检查。
测试二：延迟向B送达。A与B暂时拥有不同待处理列表。这说明本地可见不等于全网可见。
测试三：让访问服务停止回答，但A和B继续工作。读者失去常用视图，两个节点却仍然通信。
练习刻意不完整，不定义安全共识协议、密码学签名方案或生产网络。它只是让三项责任可见：传递信息、检查信息、呈现信息。
阅读节点图时值得问的问题
- 每个符号代表哪个软件实例？
- 哪家机构运行它并控制更新？
- 它接收和转发什么消息？
- 它独立执行哪些规则？
- 它保存什么数据，能回答哪些查询？
- 它是否出块或承担额外共识职责？
- 哪个服务提供最终用户的视图？
- 对等节点、客户端或访问服务失效时怎么办？
能够回答这些问题的图，比简单地在链条图标周围摆满相同计算机更有帮助。
检查你的理解
问题一：每个节点都会挖矿或提出区块吗？
答案：不会。网络参与、验证与出块是不同角色，如何组合取决于协议和配置。
问题二：待处理交易是否存在于一个全球统一队列？
答案：不一定。节点维护本地待处理信息，收到或保留的内容可能不同。
问题三：API响应自动就是密码学证明吗？
答案：不是。通信格式与验证不同。应检查应用核验什么证据，而不是假定RPC连接证明答案。
问题四：区块浏览器不可用，是否意味着链停止？
答案：不是。浏览器是访问与展示服务，它自身故障不能单独确定底层网络状态。
常见问题
客户端与钱包一样吗？
不一定。本文中的客户端指协议实现；钱包管理用户交互与授权，可能从其他服务获取网络数据。软件产品可以组合功能，因此要检查真实角色。
保存全部历史，会让节点更诚实吗？
不会。数据保留与诚实是不同性质。更多历史可以支持查询分析，但运营者、软件和验证过程仍然重要。
学区块链必须运行节点吗？
不必。可以先学角色、消息路径和验证假设。纸笔练习足以探索核心区别，无需真实账户或安装软件。
接下来学什么？
理解交易怎样改变状态，以及区块怎样记录有顺序的变化。这样才能把网络中的消息流动，与账本含义连接起来。
资料来源与范围
基础研究参考资料的日期为2026年10月12日，时区为新加坡。以下一手文档为本文进行了核查。它们持续更新；实际部署应查阅当前具体版本指引。
- 以太坊：节点与客户端：软件、角色与网络观察的限制。
- 以太坊：节点架构：执行、共识与验证者职责。
- 以太坊：轻客户端：使用有限数据验证。
- 以太坊：JSON-RPC API：应用接口。
- 比特币：点对点网络：比特币节点发现与消息转发。
- 比特币：运行模式：验证方式；历史实现细节需要重新核对。
阅读网络图时，应问每个参与者检查什么，而不只是数页面上有几台计算机。