重复验证既是区块链的保护,也是它的税。全网不能把每台机器的算力简单相加,因为许多节点在复算同一工作。
Ethereum · Chapter 16 · Lesson 01
为什么不能把区块做大 100 倍?
中心化服务可以换更大的服务器,公共区块链却要求许多互不信任的人独立核验同一历史。 本课要拆开的正式主题是区块链三难问题:去中心化、安全性、可扩展性: 不是背一个三角形,而是看清每一次“更快”把成本和信任移到了哪里。
Scalability field / continuous frontier
VERIFICATION BUDGET
区块参数不是免费的旋钮。放大负载会同时挤压传播、执行、状态访问、磁盘、同步追赶与普通人运行节点的余量。
三难问题不是“永远只能选二”的定理。密码学、采样与模块化能移动边界,但每种方案仍必须公开新的信任与失败假设。
00 / ORIENTATION
为什么服务器可以直接扩容,公共链却不能?
中心化系统优化一个可信运营者的服务;公共链要让互不信任的人得到同一可核验结果
想象一家视频网站遇到流量高峰。它可以购买更快的 CPU、在更多机房部署副本、把数据库拆分, 再由公司内部决定哪个副本是权威。用户主要相信的是公司会正确运维、不会悄悄改账,也会兑现账户规则。
公共区块链面对的是另一道题:没有一个天然可信的数据库管理员。陌生节点收到交易和区块后, 要依据公开规则决定它们是否有效;即使区块生产者、热门 RPC、浏览器或大多数有影响力的机构同时说 “这是真的”,能够完整核验的客户端仍应拒绝违反规则的状态转换。
信任运营者的数据库
内部扩容
主要信任:管理员权限、内部审计、合同与法律救济。拆库或加机器不需要让全世界逐笔复算。
把候选结果交给独立核验
接受或拒绝
主要目标:不必把有效性完全托付给单一运营者;但每个核验者都要承担下载、执行、状态访问和追赶成本。
- 先建立最小心智模型
- 中心化服务的容量大致可以通过增加受同一控制的机器横向扩展;简单全复制区块链的 全网处理上限则受一台普通核验节点在截止时间内能持续处理多少工作约束。 节点数量增加提升冗余、可获得性与独立核验者数量,却不会自动让同一条链把更多交易并行执行。
01 / OPERATIONAL DEFINITIONS
先给三个词装上可检查的刻度
不要用“节点很多”“从未停机”“TPS 很高”替代完整定义
三难问题之所以容易争吵,是因为三个人说着同一个词,心里却测量着不同对象。 一条链可以在某个指标上高度分散,在另一个控制点上依然集中;也可以在正常天气里很快, 在网络分区、攻击或节点追赶时暴露完全不同的边界。
去中心化:不是一个节点计数器
开放加入
新人是否能获得软件、数据与协议规则,自行接入生产、核验或退出,而不需要少数管理员发许可证。
独立核验
普通参与者能否用自己选择的客户端拒绝无效区块,而不是只能相信浏览器、RPC 或几个超级节点的回答。
控制权分散
出块、质押、客户端实现、升级协调、关键基础设施与数据入口是否被多个独立主体掌握。
故障不相关
节点是否跨地区、网络、云厂商、操作系统和客户端;一张账单、一个漏洞或一道命令会不会同时击倒多数参与者。
因此,十万个验证者地址不等于十万个独立运营者。一个托管商可以控制很多验证者密钥, 同一实体也可以在同一云区运行成百上千个实例。地址数、质押份额、节点数、运营主体数和客户端多样性 都有信息,但没有任何一个数字能单独代表“去中心化”。
安全性:至少分成四种保证
有效性
违反状态转换规则的交易或区块能否被完整核验者发现并拒绝,即使有影响力的生产者支持它。
共识安全与最终性
诚实参与者是否会对冲突历史同时作出不可轻易撤销的承诺;需要攻击者掌握多大权重才能破坏它。
活性与抗审查
在部分节点离线、网络受阻或生产者审查时,有效交易最终能否进入,链能否继续前进。
检测、退出与恢复
故障能否被独立观察;用户是否保有数据、证明和退出路径;社会协调能否围绕可核验事实恢复。
可扩展性:需求增长时,谁必须增加多少工作?
- 操作性定义
- 可扩展性不是单独一个峰值 TPS。它描述系统在需求增长时,能否提高有用容量,同时把核验成本、延迟、 费用、状态增长和信任假设维持在目标范围内。Vitalik 在三难问题原始表述中更严格地把它描述为: 链能处理超过单台普通节点可以完整核验的交易量。
这个定义刻意把“系统总容量”和“每台核验者负担”拆开。若容量翻十倍必须让每个完整节点的 CPU、网络和磁盘 也翻十倍,那更像是提高机器门槛,而不是从架构上扩展。真正的扩展技术尝试让总工作增长快于每个参与者必须承担的工作, 但通常会引入证明、采样、分工、同步假设或新的复杂性。
NOT A SLOGAN
02 / SIMPLE TECHNIQUES
“只能选二”到底说了什么,又没说什么?
原句有一个经常被海报删掉的限定词:simple
“if you stick to ‘simple’ techniques, you can only get two of those three.”Vitalik Buterin · Why sharding is great · 2021-04-07
精确翻译是:如果坚持使用“简单”技术,三项中只能得到两项。这里的简单技术包括把所有工作交给少量高性能节点、 让每个普通节点完整处理全部交易,或把系统拆成许多安全彼此独立的链。它不是声称宇宙中存在一条数学定律, 永远禁止三项同时改善。
“选二”作为入门口诀
提醒你:直接提高区块上限或缩短时间,往往用更高节点门槛换容量;减少核验者,又改变去中心化和攻击假设。
“连续前沿”作为工程模型
现实系统不是三个开关。客户端优化、证明、采样、网络改进和硬件进步可以把可行边界向外推,但无法取消物理资源与信任分析。
“同名指标”也可能不可比
两条链都说高吞吐,一条要求家庭宽带全节点,另一条依赖许可数据委员会;数字相同,安全对象并不相同。
边界会随时间移动
普通硬件更快、客户端更高效、协议加入新证明后,安全容量可以提高;但路线目标不是已经兑现的运行事实。
这是分析清单,不是可计算的协议函数。它的用途是防止把“TPS”当作唯一自变量, 并迫使设计者写清楚每项改进依赖什么条件。
03 / REPLICATION TAX
同一笔交易,为什么要被许多人重复处理?
复制不是低效实现留下的偶然瑕疵,而是无需信任单一运营者的成本来源
在最直观的全复制模型里,一笔交易被广播,区块生产者把它装入候选区块,随后许多完整节点重新下载数据、 验证签名与规则、执行状态转换,并更新自己的数据库。每个节点得出同一结果,才能独立拒绝造假。
执行
状态读写
执行
状态读写
执行
状态读写
执行
状态读写
执行
状态读写
这带来一个容易误解的事实:增加完整节点不会把同一条全复制链的执行吞吐简单相加。十台节点不是十台并行应用服务器, 而更像十位独立审计员复算同一本账。系统得到的是冗余、抗单点故障、数据服务和更多独立判断者; 吞吐上限仍受较弱但希望保留在网络中的普通节点能否及时完成同一负载约束。
把瓶颈写成四条教学不等式
λ × b ≤ Bbandwidth
λ × s ≤ Sstate/storage
Tpropagation ≈ Lnetwork + bytes ÷ bandwidtheffective
λ 表示单位时间的工作量;c 是每单位工作的计算与状态访问成本;b 是必须传播的数据量; s 是对状态或存储增长的近似贡献。C、B、S 是为普通节点保留安全余量后的可持续预算。 传播式把基础网络延迟与传输时间拆开。
普通节点需要的不是“平均能跑”,而是峰值余量
节点在理想实验室里刚好追上区块还不够。它还要面对网络抖动、重组、数据库压缩、客户端升级、机器重启、 同时服务 RPC 请求,以及离线数小时后的追赶。如果正常负载已经长期吃满 CPU 或带宽,任何异常都会形成积压: 新区块继续到来,旧工作尚未完成,延迟随队列累积。
因而合理预算会保留余量,并观察较慢地区和较普通设备的尾部表现,而不只看高端机房的平均值。 去中心化的成本不是“世界上有没有机器能跑”,而是“足够多彼此独立的人是否仍愿意且能够跑”。
04 / BLOCK PRESSURE
把区块做大、做快,压力会沿哪条链传下去?
容量参数先改变每个节点的截止时间与工作队列,然后才可能改变用户看到的吞吐
“区块扩大 100 倍”听起来像把货车换成更大的车。问题是,公共链上的每一个完整核验者都要在下一轮共识需要它之前 收到这辆车、拆开货物、检查每件物品、执行其中的程序并更新本地账本。区块越大,单轮工作越多; 区块越快,同样工作可用的时间越短。
更多字节跨不同地区、带宽与对等连接扩散,慢节点更晚看到候选区块。
签名、Gas 规则、EVM 执行与证明检查必须在协议时间窗内完成。
合约读写触碰数据库;随机 I/O、缓存失配和状态规模会影响实际延迟。
更多历史数据、快照与状态增长,使新节点同步和故障恢复更艰难。
设备、宽带、运维和云成本上升,一部分独立运营者转而依赖托管与 RPC。
大区块的五重压力,不是一条“磁盘变大”就能概括
传播压力
区块越大,尾部节点收到完整数据越晚。传播延迟差异会给网络位置好、带宽高的生产者更多优势,也缩短其他节点核验和响应的窗口。
执行与 CPU 压力
交易不是等长文本。有的状态转换计算重、签名多或访问大量状态。只按字节估算会漏掉 EVM 与密码学验证成本。
状态与数据库压力
历史区块可以采用不同保留与剪枝策略,但当前活跃状态需要被频繁读取。状态增长会改变缓存命中、磁盘随机访问和快照维护成本。
同步与恢复压力
节点不是只从今天开始运行。新节点要引导、验证可信起点后的数据;旧节点离线后要追赶。增长率会决定它是否永远追不上链头。
服务外溢压力
全节点还可能服务对等网络、RPC、索引和本地应用。协议验证刚好满载时,这些功能会竞争同一 CPU、内存、磁盘和上行带宽。
社会与运营压力
当家庭设备退出,剩余节点更可能集中在专业团队、同类硬件和少数云厂商。一次漏洞、封禁或云故障的相关性随之提高。
快区块不是把同样的工作免费切碎
假设每 12 秒处理一批工作,现在改成每 1.2 秒一批。即使每批缩小,固定网络往返、共识消息、数据库提交和调度开销仍然存在; 地理距离造成的延迟也不会缩小十倍。时间窗越短,稍慢节点越容易在看到新区块时,下一个区块已经开始传播。
更快的出块节奏还可能改变分叉、迟到、提议者优势与共识稳定性,具体后果取决于协议。不能把“出块更频繁” 直接等同于“最终确认同比更快”,也不能把它直接等同于“每笔成本更低”。吞吐量、确认时间与成本之间的定量关系, 是第十六章第二课的范围。
教学模型:余量长期为正,节点才有机会在离线后追上;接近零时,短暂抖动就会形成积压; 为负时,再快的初始同步技巧也无法让该设备持续跟上。两项速率都不是单一 TPS。
05 / NODE ROLES
验证者、全节点、归档节点、轻客户端与 RPC 用户不是一回事
谁参与共识、谁完整执行、谁保存历史、谁验证证明、谁只是询问服务商,必须分开统计
“网络有很多验证者,所以任何用户都能独立验证”是错误推理。节点角色回答的是不同问题: 有人负责提出或证明共识消息,有人逐块执行规则,有人保留全部历史状态,有人只核验摘要与证明, 还有大量用户只从远程接口读取结果。
验证者
用验证者密钥提出区块或签署共识证明,并承担奖励与惩罚。
全节点
下载区块体,按协议规则执行并验证区块与状态,可在不质押的情况下运行。
归档节点
首先是全节点,再额外保存可查询的历史状态,服务浏览器、分析和追踪。
轻客户端
验证区块头、共识或状态证明,并向完整数据提供者请求所需内容。
RPC 用户
钱包或应用向远程节点询问余额、区块、模拟与交易状态。
| 角色 | 完整执行新区块 | 参与 PoS 共识职责 | 保存全部历史状态 | 主要信任或资源边界 |
|---|---|---|---|---|
| 验证者 | 通过所连执行节点 | 是 | 不要求 | 密钥、节点连接、运营主体与质押集中 |
| 全节点 | 是 | 不一定 | 不要求,可剪枝 | 本地 CPU、带宽、磁盘、客户端实现 |
| 归档节点 | 是 | 不一定 | 是 | 额外磁盘、索引与长期运维 |
| 轻客户端 | 否 | 通常否 | 否 | 证明机制、数据响应与同步假设 |
| 普通 RPC 用户 | 否 | 否 | 否 | 提供者诚实、在线、不审查且不泄露查询 |
06 / THREAT MODEL
说“安全”,必须先说攻击者能做什么
安全不是产品标签,而是一组在明确条件下成立的命题
一套扩容方案可能对“少数生产者宕机”很稳健,却依赖一个升级委员会不作恶;可能用密码学证明执行正确, 却把交易数据放在用户无法独立恢复的地方;也可能保证无效状态进不来,却无法阻止长期审查。
协议试图验证或约束
- 状态转换是否遵守公开规则
- 冲突历史是否获得足够共识权重
- 区块或证明是否在规定窗口内有效
- 惩罚、签名与分叉选择是否符合规范
设计仍要公开的假设
- 谁能生产、排序或审查交易
- 数据是否及时可得、谁负责保存
- 升级、暂停和紧急密钥由谁控制
- 客户端、云和网络故障是否相关
- 运营者消失时用户如何退出与恢复
一份最小威胁模型至少回答六类攻击
无效状态
攻击者伪造余额或执行结果时,谁完整执行、谁验证证明、无效结果能否被本地客户端拒绝?
共识权重攻击
达到什么质押、投票或委员会阈值可以阻断最终性、重组或制造冲突承诺?阈值是否集中在少数运营者?
审查与排序
少数生产者能否长期排除交易?用户能否直接提交、换入口、等待其他生产者或证明审查发生?
数据扣留
即使结果数学上有效,用户是否获得重建状态、生成后续证明或退出所需的数据?“有效”不自动等于“可用”。
相关故障
同一客户端漏洞、云区宕机、网络封锁或自动升级会同时影响多少权重和核验能力?节点实例多也可能同源失败。
控制面接管
升级、参数、桥、证明器白名单或紧急暂停由谁改变?需要多少人串谋,用户能否拒绝并带走资产或状态?
- 信任假设的正确写法
- 不写“无需信任”,而写:在攻击者控制不超过 X 权重、至少一个诚实数据提供者存在、网络延迟不超过某窗口、 证明系统健全、升级密钥未串谋等条件下,系统保证哪些性质。不同层的 X 和“至少一个”可能完全不同。
07 / ARCHITECTURES
四种架构不是“快慢榜”,而是信任与工作分配图
比较谁生产、谁验证、数据在哪里,以及需求增长时每个普通参与者必须多做什么
中心化服务
运营者可分库、复制、缓存并用内部共识协调机器,用户不逐笔复算。
- 容量:容易横向增加
- 核验:内部审计或用户抽查
- 恢复:合同、备份、法律与管理员
保守全复制 L1
许多普通节点处理同一交易流,以较低单节点负载换广泛独立核验和恢复能力。
- 容量:受普通节点预算约束
- 核验:每个全节点完整执行
- 恢复:本地规则与多实现生态
高容量全复制 L1
直接提高区块或频率;若验证仍全复制,每个节点同步增加下载、执行和状态负担。
- 容量:短期参数提升直接
- 核验:趋向专业硬件与机房
- 恢复:依赖能运行高负载节点的人
证明、采样与模块化
把执行、结算、共识和数据可用性分工,用密码学证明或抽样降低每位核验者直接处理的工作。
- 容量:总工作可快于单节点负担增长
- 核验:验证证明、挑战或数据样本
- 恢复:依赖数据、时序与退出设计
独立多链或侧链还会引入另一种分工:每条链只处理自己的交易,因此总容量可以增长;但安全是否共享取决于具体机制。 若攻击者只需控制其中最小的一条链,系统总节点或总质押不能自动保护它。跨链消息又把一个域的故障传播给另一个域。
08 / CAPACITY LAB
容量增加多少,普通节点的压力才没有越界?
用三个滑杆观察:负载、效率和节点预算必须放在同一个分母里讨论
下面不是以太坊性能计算器,而是一台概念显微镜。它把“基础工作负载”“软硬件效率增益”和“希望保留的普通节点预算” 放进同一比率,帮助你看见某个提案究竟靠效率扩大安全容量,还是靠提高准入门槛。
Local interactive · conceptual model
普通节点压力比
使用原生滑杆,支持键盘方向键、触摸和鼠标。数据只在本页内计算, 不连接节点、不读取设备性能,也不保存设置。
Teaching relation
P 只表示概念压力比:负载除以效率调整后的普通节点预算。
当前负载经过 2.0× 效率增益后,占用普通节点概念预算的 75%。系统仍能处理, 但留给网络抖动、追赶、重组与服务请求的余量已经收窄。
怎样读这个比率
P < 0.6 · 有明显余量
教学模型认为节点有空间处理尾部延迟与追赶。但这不证明协议安全;真实系统还要分别测 CPU、网络、状态 I/O 与共识时间窗。
0.6 ≤ P ≤ 1 · 边缘区
平均设备可能跟上,较慢地区和异常时段先承压。若只展示高端设备均值,会掩盖去中心化门槛正在提高。
P > 1 · 越过目标预算
在给定假设下,目标普通节点无法持续处理。设计必须降低负载、提高真实效率、改变分工,或承认节点人群会缩小。
P 不是去中心化分数
它没有包含运营主体、质押集中、客户端、云、地域、数据可用性或升级权。它只防止把容量提案写成没有分母的倍数。
09 / SEVEN-QUESTION AUDIT
看到任何“扩容 100 倍”,先问这七个问题
目标不是立刻否定,而是把营销倍数翻译成生产、验证、资源、攻击、数据与退出路径
- 谁生产结果? 区块、批次、证明或数据承诺由开放生产者、轮换委员会、许可运营者还是单一排序者生成?别人能否加入或绕过审查?
- 谁验证,验证什么? 每个全节点是否重执行全部工作;还是验证证明、挑战窗口、签名委员会或数据样本?普通用户实际运行哪一种验证路径?
- 需求增长时,资源负担怎样变化? 容量翻倍会让谁的 CPU、带宽、内存、状态 I/O、历史数据与追赶时间翻倍?瓶颈是否只是从执行移到证明器或数据网络?
- 攻击者或控制者需要多少权力? 多少质押、生产份额、委员会成员、升级签名或云控制面可以破坏有效性、最终性、活性或抗审查?地址数是否来自独立主体?
- 数据在哪里,谁保证可用? 验证结果所需的数据是否公开、及时、可重建?是每个节点下载、随机采样、委员会保管,还是只由运营者承诺?保留多久?
- 运营者失败时如何退出与恢复? 用户是否持有退出所需证明和数据?能否无需许可回到安全层?升级、暂停或桥故障时,谁能冻结、替换或分叉?
- 瓶颈和信任究竟移到了哪里? 总容量上升后,是普通核验者负担下降了,还是工作集中到高端生产者、少数证明器、数据服务、RPC、桥或治理委员会?
把答案压缩成一张审计卡
| 维度 | 必须写出的事实 | 不能用来代替它的口号 |
|---|---|---|
| 生产 | 准入、排序、审查绕行、生产者故障 | “任何人都能发交易” |
| 验证 | 本地执行或证明路径、最坏成本、软件实现 | “密码学保证” |
| 资源 | CPU、带宽、状态、磁盘、同步、尾部余量 | “普通电脑可运行” |
| 控制 | 攻击阈值、运营实体、密钥和升级权 | “有很多验证者” |
| 数据 | 发布、采样、保留、恢复与扣留后果 | “数据在链上” |
| 退出 | 运营者消失、恶意或升级失败时的用户路径 | “继承 L1 安全” |
10 / MISCONCEPTIONS
八个最常见的三难问题误读
纠正的关键不是换一个口号,而是把被省略的分母、角色和假设补回来
TPS 高就等于可扩展
纠正:峰值吞吐只描述一种负载下的产出。可扩展性还要看普通核验成本、状态增长、数据可用性、延迟和需求增长曲线。
验证者地址越多越去中心化
纠正:一个运营者可控制许多密钥。要看独立主体、质押份额、客户端、云、地域与故障相关性。
硬件每年更快,所以参数随便涨
纠正:状态与需求也在增长,全球带宽和延迟不均,去中心化目标还取决于希望保留哪些普通参与者。
轻客户端让全节点成本不再重要
纠正:轻客户端降低用户负担,但仍需要足够完整的数据与证明服务;若完整核验者极少,生产和恢复可能集中。
数据可用就等于永远存档
纠正:可用性通常关心某时窗内是否能取得足够数据以验证或恢复;永久历史保存是另一种服务与成本。
用了 L2 就自动解决三难
纠正:L2 的证明、数据、排序、升级和退出设计各不相同;有的继承更多 L1 性质,有的明确接受额外信任。
三角形证明所有链永远只能选二
纠正:原表述限定“简单技术”。证明、采样与分工可以移动连续前沿,但不能免除资源和威胁模型。
区块更大只是多买硬盘
纠正:传播、执行、状态 I/O、缓存、同步与运营门槛同时变化;历史磁盘只是压力链的一段。
11 / ETHEREUM BRIDGE
以太坊的方向不是“L1 不扩”,而是让 L1 与 L2 各自扩展
这是 2026 年路线意图的桥接说明,不是“已经解决三难问题”的事实宣告
以太坊长期重视让普通参与者保有独立验证路径,但这不等于把 L1 容量冻结。 以太坊基金会在 2026 年阐述的 L1 + L2 视角,是让 L1 本身在尽量保持最高安全性与去中心化的同时实现数量级扩展, 并让多样化 L2 提供额外规模、功能、定制和不同控制空间。
L1 自身也要扩展
- 保持无许可核验、韧性与共享状态中心
- 通过客户端、协议、证明与数据技术提高安全容量
- 为结算、流动性、DeFi 与其他层提供坚实基础
L2 提供额外规模与差异化
- 功能、隐私、定价、排序和应用专用环境
- 与 L1 的安全关系存在完整光谱
- 必须透明说明证明、数据、升级、退出与互操作假设
三类技术信号,只说明“边界怎样被推动”
EIP-4844 · 专用数据空间
Blob 交易把扩展数据与普通 EVM 执行负载区分,为上层发布数据提供专门的费用与承诺机制。它提高可用数据路径,不等于每个全节点永久保存所有 Blob。
PeerDAS · 已部署的数据抽样
PeerDAS 已随 2025 年 12 月的 Fusaka 升级部署:节点持有并抽样 Blob 数据的一部分,而非每个节点下载全部 Blob;这让数据容量可以快于单节点下载负担增长,安全仍依赖编码、抽样与足够参与者。
EIP-7870 · 写出硬件预算
硬件与带宽建议把“普通节点能否运行”变成可讨论的基准。它不是永恒保证,而是参数演进时必须持续测量的目标约束。
L1 + L2 · 互补而非唯一通道
L1 计划扩大自身能力;L2 继续提供额外规模与定制。任何一层的路线都要通过实验、实现、测量和真实用户退出能力验证。
12 / RECAP
把三难问题折回一条可验证链路
容量不是凭空生成:要么提高效率,要么改变分工,要么提高资源门槛,要么增加信任
| 观察层 | 核心问题 | 健康信号 | 危险偷换 |
|---|---|---|---|
| 去中心化 | 谁能开放加入、独立核验、控制与从故障中幸存? | 低门槛验证、主体与客户端多样、故障不相关 | 用验证者地址数代替独立运营者 |
| 安全性 | 对什么攻击保证有效性、共识安全、活性与恢复? | 阈值和假设明确,数据与退出可验证 | 用“主链安全”覆盖应用、桥和升级密钥 |
| 可扩展性 | 需求增长时,每位普通核验者多承担多少工作? | 总容量快于单节点负担增长,且保留余量 | 只报峰值 TPS,不报验证与状态成本 |
| 参数扩容 | 传播、执行、状态、磁盘和追赶是否仍在预算内? | 最坏负载、尾部设备与异常恢复均有测量 | 把高端机房基准当作全球普通节点 |
| 模块化 | 证明、数据、排序、升级和退出分别由谁负责? | 性质与信任边界透明,运营者消失仍有路径 | 仅凭“L2”标签宣称完整继承安全 |
六题检查你是否真的理解
1. “区块链三难问题”最精确的入门理解是哪一个?
选择答案后查看解析。
答案:B。原表述限定使用“简单”技术时只能得到三项中的两项;证明、采样与模块化可以移动连续前沿,但仍有资源和信任假设。
2. 为什么“把区块做大”不只是多买一块硬盘?
选择答案后查看解析。
答案:C。更大的区块同时增加传播字节、执行、状态 I/O、历史增长和同步追赶压力;磁盘只是完整压力链的一段。
3. 下列关于验证者和全节点的说法,哪一个正确?
选择答案后查看解析。
答案:A。全节点可以不质押而完整验证区块;验证者承担共识职责并连接节点。一个运营者还能控制许多验证者索引。
4. 在容量实验中,负载 W 翻倍、效率 E 也翻倍、预算 B 不变,压力比怎样变化?
选择答案后查看解析。
答案:B。P = W ÷(E × B)。W 和 E 同时翻倍、B 不变时,比值不变;这表示效率刚好抵消新增概念负载。
5. 钱包通过远程 RPC 读取余额,默认获得的是什么?
选择答案后查看解析。
答案:C。普通 RPC 响应主要是提供者的陈述。若钱包没有另行核验状态证明,就依赖提供者的正确性、在线性、抗审查与隐私处理。
6. 哪一句最符合当前以太坊 L1 + L2 的路线表述?
选择答案后查看解析。
答案:A。2026 年 EF 视角是 L1 本身计划数量级扩展并尽力保留安全与去中心化,同时 L2 提供额外规模与差异化;这是待验证的路线目标。
13 / GLOSSARY & SOURCES
术语与一手资料
定义优先回到协议、ethereum.org、EIP 与作者原文;路线和硬件边界会继续变化
本课最小术语表
- Scalability trilemma
- 用去中心化、安全性、可扩展性之间的约束分析区块链设计;“简单技术选二”是启发式,不是普适定理。
- Decentralization
- 开放加入、独立核验、控制分散以及故障不相关等多维性质,不等于单一节点或地址计数。
- Validity
- 状态转换是否遵守协议规则;完整节点可独立拒绝无效区块。
- Consensus safety
- 诚实参与者不会同时对冲突历史作出不可兼容的最终承诺。
- Liveness
- 在允许的故障和网络条件下,链能继续前进,有效交易最终有机会被处理。
- Replication tax
- 许多节点重复下载、执行与保存同一工作,以换取无需信任单一运营者的核验和冗余。
- Full node
- 下载区块体并逐块验证执行与状态的节点;无需成为验证者。
- Validator
- 使用质押与验证者密钥承担提议、证明等 PoS 共识职责的角色。
- Archive node
- 完整验证并额外保留可查询历史状态的全节点,磁盘需求高但不获得额外共识权。
- Light client
- 验证头、共识或状态证明,并从其他节点请求所需数据的轻量核验者。
- RPC
- 钱包与应用向节点读取链数据或提交交易的接口;远程 RPC 通常引入提供者信任与隐私边界。
- Data availability
- 验证或恢复状态所需的数据是否在关键时间窗内可取得,不等于永久归档。
- Data sampling
- 通过随机请求编码数据的一小部分,高概率判断整体数据是否可获得的方法。
- Safety margin
- 节点在平均负载之外,为抖动、追赶、重组、数据库维护和服务请求保留的资源余量。
- Modular architecture
- 把执行、结算、共识与数据可用性拆给不同组件,并用证明或消息连接的系统设计。
- Trust assumption
- 某项安全保证成立所需的攻击阈值、诚实参与者、网络时序、数据与治理条件。
官方、标准与作者原文
-
[01]
Ethereum.org · What is layer 2?
L2 的基本定位、与以太坊主网的关系,以及不同网络需要分别核查的安全与用户风险。
-
[02]
Ethereum.org · Scaling
以太坊扩展问题、链上与链下方案、Rollup 与其他技术的官方开发者概览。
-
[03]
Ethereum.org · Nodes and clients
执行客户端、共识客户端、验证者,以及 full、archive、light 节点角色的官方说明。
-
[04]
Ethereum.org · Spin up your own Ethereum node
运行节点的组成、同步、设备与网络考虑,以及独立验证对使用者和网络的价值。
-
[05]
Ethereum.org · PeerDAS
已随 Fusaka 部署的对等数据可用性采样:通过分发数据列与抽样降低单节点下载负担,并为逐步提高 Blob 容量提供基础。
-
[06]
Ethereum.org · Data availability
为什么有效性之外还需要数据可用性,以及链上、委员会与采样方案的差异。
-
[07]
Vitalik Buterin · Why sharding is great
三难问题的“simple techniques”原始表述,以及可扩展、去中心化和安全的操作性定义。
-
[08]
Vitalik Buterin · The Limits to Blockchain Scalability
普通用户运行节点的重要性,以及计算、带宽、存储、状态访问和网络延迟对扩展的约束。
-
[09]
EIP-4844 · Shard Blob Transactions
Blob 交易、独立费用市场、版本化哈希与数据生命周期的规范。
-
[10]
EIP-7870 · Hardware and Bandwidth Recommendations
以太坊节点硬件与带宽建议,用于让协议参数变化保持可测量的资源目标。
-
[11]
Ethereum Foundation · How L1 and L2s can build the strongest possible Ethereum
2026 年 L1 + L2 视角:L1 计划自身数量级扩展并保持核心性质,L2 提供额外规模、功能与差异化;部分目标仍需实验验证。