01 · Orientation
先把结论放在桌上
“世界计算机”是一个有用的入口，但先要把隐喻说精确。
第三章收束 · 先建地图，后续章节再拆机器
更准确地说，以太坊是一台公开、复制、确定性的状态机： 它接收一组有顺序的交易作为输入，按照协议规则执行，再从旧状态得到新状态。 许多彼此不必信任的节点，都能独立检查这一步是否正确。
某个数据中心先算出结果，再把结果同步给世界。
提议路径先构造并执行一个有序候选；其他完整节点本地重放核验，共识再让其中一条执行有效的历史逐步成为规范历史。
这里的“全网”也不是说每一部手机、每一个浏览器钱包都保存全部数据、执行全部交易。 它指的是网络中许多独立运营的完整执行节点可以重放并验证状态转换； 轻客户端、钱包和 RPC 用户处在不同的验证边界。
以太坊的核心产品不是“计算速度”，而是一个任何人都能提交请求、 任何人都能验证结果、没有单一管理员能随意改写的共享状态。
学完本课，你应该能做到
摆对位置
把主网、共识层、执行层、EVM 与智能合约放进同一张架构图。
追踪因果
从钱包签名出发，追踪一次调用如何变成新的合约存储与状态根。
分清职责
区分“执行结果有效”与“哪段有效历史成为规范历史”。
看见代价
解释为什么重复执行带来独立验证，也必然牺牲成本、吞吐与隐私。
02 · Assembly
五个部件，不是五台并列的机器
它们分属网络实例、协议职责、执行环境与链上程序四个不同层次。
初学者最容易把这些词看成一串品牌名。更好的方法，是给每个部件只问两个问题： 它负责什么？它明确不负责什么？
主网Mainnet
真实运行的公共生产网络，使用真实 ETH 承担费用与经济后果；它不是一台主服务器。
共识层Consensus layer
在有效候选中跟踪规范链头、证明与最终性；它不直接解释 Solidity 函数。
执行层Execution layer
验证交易、管理交易池与世界状态、重执行执行载荷；它不能单独宣布哪条分支是最终历史。
EVMExecution environment
规定字节码怎样一步步改变机器状态并计算 Gas；它是规则环境，不是某台物理电脑。
智能合约Code + persistent storage
位于链上地址的代码与持久数据；它不会自行醒来，必须被交易或其他合约调用触发。
Ethereum 是协议、网络与状态机体系；ETH 是其原生资产， 用于支付 Gas、质押并承载经济价值。ETH 不是由某份 ERC-20 合约发行的普通代币。
一台真实节点内部，还要再分软件
合并后的完整节点通常同时运行执行客户端和共识客户端。 两者连接各自的 P2P 网络，并通过本机的 Engine API 协作。 只有要参与提议和证明时，节点运营者才再运行验证者职责并质押。
03 · State transition
全球计算机真正共享的，是“状态”
区块保存历史输入；状态回答“此刻世界是什么样”。
执行层的世界状态包含账户及其信息：余额、nonce、合约代码和合约存储等。
每个区块执行后，节点都得到一个新的 post-state，并用一个紧凑的
stateRoot 对它作密码学承诺。
这里特意写出“顺序”和“区块环境”： 合约可以读取调用者、转入金额和部分区块上下文；同一批交易换一个顺序， 结果可能不同。确定性不是“无论怎么排都一样”，而是 同一起点 + 同一有序输入 + 同一协议规则 = 同一结果。
一次 increment() 调用前后
- Alice.nonce
- 7
- Alice.balance
- 3.200 ETH
- Counter.code
- 0x60…
- Counter.slot[0]
- 2
- Alice.nonce
- 8
- Alice.balance
- 3.199… ETH
- Counter.code
- 0x60…
- Counter.slot[0]
- 3
执行层世界状态保存账户与合约数据；共识层的 BeaconState 保存验证者集合、 检查点等共识信息。两边都有“state root”，但承诺的对象、编码和职责不同。
04 · End-to-end
跟着一笔调用，穿过整套架构
从用户意图到全网可验证的新状态，中间没有“神奇同步”这一步。
Signed request
- from
- 0xAlice
- to
- 0xCounter
- nonce
- 7
- calldata
- increment()
- value
- 0 ETH
- fee caps
- max fee / priority
- signature
- r · s · yParity
Intent → state transition
Counter.slot[0] : 2 → 3钱包只表达并签署请求。它不能直接写合约存储；真正的写入必须通过协议检查、 EVM 执行、区块承诺和其他节点重放验证。
Interactive · call journey
逐步查看一笔调用经过哪里
钱包把意图变成可验证的指令
钱包构造交易字段并用账户密钥签名。签名证明授权；nonce 约束账户交易顺序并防止同一交易被重复使用。
最容易漏掉的一步：其他节点不是下载“答案”
区块传播后，接收它的完整节点会在本地再次检查并执行交易， 计算出自己的 post-state 与收据，再核对区块执行载荷中的承诺。 如果本地算出的状态根不一致，这个执行载荷就不能被视为有效。 传播的是输入、区块数据与根承诺；信任来自可重算，而不是来自提议者信誉。
交易选择与区块构建可能涉及本地交易池、专业构建者和 MEV-Boost 等路径。 这些路径会影响候选交易的选择与排序，但不会获得绕过执行有效性规则的权力。 本课先保留协议主线。
05 · Determinism lab
为什么四台机器不会算出四个答案？
不是因为它们互相取平均，而是因为规则刻意排除了未约定的自由度。
EVM 的协议语义必须让不同语言、不同团队编写的客户端实现，对同一个有效输入得到同一个结果。 合约不能直接读取某台机器的系统时间、随机文件或随意请求互联网 API； 否则节点会自然分叉。
Interactive · same inputs, same result
换顺序，或让一个节点“擅自改答案”
起点 counter = 0
这个实验说明两件不同的事。第一，交易顺序是输入的一部分： B → A 得到 5 并不违反确定性。第二，某个节点本地算错并不会迫使其他节点妥协； 它的根承诺与规范执行不一致，会被诚实节点拒绝。
确定性来自哪些约束？
输入被明确定义
交易字段、调用数据、当前状态和协议允许读取的区块上下文，都进入可重放的输入边界。
顺序被区块固定
交易在执行载荷中的先后次序明确；后一个交易看到的是前一个交易产生的状态。
操作语义被协议固定
操作码、Gas、异常与分叉规则必须一致，客户端实现可以不同，结果不可以不同。
结果可以被紧凑核对
状态根、收据根等承诺让节点对“我算到哪里”形成可比较的密码学摘要。
06 · Two gates
“算得对”与“被网络采用”是两道门
执行层负责有效性，共识层在有效候选之间推进规范历史。
这份执行结果有效吗？
执行客户端检查交易与执行载荷是否符合当前协议规则。
- 签名、nonce、余额与费用约束
- 逐笔 EVM 执行与 Gas 记账
- 状态根、收据与区块字段一致
哪一个有效候选是规范历史？
共识客户端跟踪区块、证明、分叉选择、检查点与最终性。
- 哪个 slot 的候选接在规范链头之后
- 验证者证明如何为分支提供权重
- 何时达到 justified 与 finalized
两道门缺一不可。一个执行无效的区块，不会因为得到很多“投票”就变有效； 两个都执行有效的竞争候选，也不能只靠 EVM 自己决定哪个成为规范链头。 合并后的节点通过 Engine API 让这两部分持续握手。
| 情形 | 执行层结论 | 共识层处理 | 最终结果 |
|---|---|---|---|
| 状态根算错 | 执行载荷无效 | 不得把它当成有效链头推进 | 拒绝 |
| 两个候选都有效 | 都通过本地执行 | 按分叉选择与证明权重跟踪规范头 | 其中一支规范 |
| 规范区块已最终确认 | 执行结果有效 | 回滚需要破坏显著的经济安全假设 | 历史稳定性增强 |
| 合约逻辑有漏洞 | 仍可能完全按代码正确执行 | 不会替应用审计业务意图 | 漏洞后果仍有效 |
最终性保护的是规范历史不易回滚；它不证明合约符合用户愿望，也不撤销钓鱼授权、 错误参数或安全漏洞。协议正确执行一段有缺陷的代码，仍然是“有效执行”。
07 · Why repeat?
全网重复计算，究竟买到了什么？
从普通计算机看，这是浪费；从无需许可的公共状态看，这是安全预算。
得到的能力
- 01独立可验证：不必相信某个 API 或区块提议者给出的余额与执行结果。
- 02抗单点：某个运营者宕机、拒绝服务或作恶，不会成为全局管理员。
- 03公开可组合：合约彼此可调用，共享同一结算与状态语境。
- 04规则可预期：改变执行规则需要公开的协议升级，而不是后台静默改库。
支付的代价
- 01计算昂贵：Gas 为稀缺执行与存储资源计价，也抑制无限循环与滥用。
- 02吞吐受限：完整验证者必须能跟上协议负载，否则参与门槛会上升。
- 03默认公开：链上输入与状态适合审计，却不等同于隐私计算。
- 04升级谨慎：共享规则一旦改变，所有实现都必须在同一边界上协调。
它与云服务器，不是在同一维度竞争
| 维度 | 典型云应用 | 以太坊主网 |
|---|---|---|
| 谁控制写入 | 服务运营者与其数据库权限 | 只有符合协议的签名交易与合约调用 |
| 谁验证结果 | 通常由运营者保证，用户看 API 响应 | 多个独立节点可本地重放并核对承诺 |
| 执行次数 | 尽量只算必要的几次 | 许多完整节点重复验证 |
| 性能目标 | 低延迟、高吞吐、可弹性扩容 | 全球可验证、抗单点、规则一致 |
| 数据可见性 | 可由运营者设为私有 | 执行数据与状态默认面向公开验证 |
| 失败恢复 | 管理员可回滚、修库或恢复备份 | 规范历史不能由单一管理员任意改写 |
所以，图片压缩、搜索排序、视频转码这类不需要公共共识的任务，交给普通服务器更合理； 资产所有权、开放结算、可组合金融规则等需要多方共享且彼此不愿交出控制权的状态， 才是区块链计算更有说服力的场景。
08 · Boundaries
“全球计算机”不代表无所不能
一个好隐喻的价值，在于帮你入门；成熟理解从知道它何时失效开始。
“所有节点都同时执行每一笔交易。”
更准确的说法是：许多完整执行节点会按规范区块重放并验证交易。 钱包、轻客户端、归档查询服务与验证者职责并不等价；也不是每个联网设备都保存或执行全部历史。
“智能合约会按时间表自己运行。”
合约是被动的。必须有外部账户交易或另一份合约的消息调用触发执行。 “定时任务”通常依赖外部自动化者在条件满足时提交交易。
“合约可以直接查询天气、股价或网页 API。”
直接访问任意外部数据会让各节点看到不同输入，破坏确定性。 预言机把外部事实转化为链上可消费的数据，但同时引入新的信任、延迟与操纵风险。
“共识层执行合约，然后把状态发给执行层。”
执行客户端内的 EVM 负责执行与状态有效性；共识客户端处理规范链、证明与最终性。 两者通过 Engine API 协作，不是简单的上下级转包。
“状态根相同，说明每台节点硬盘里的全部数据都完全相同。”
状态根承诺的是协议定义的执行状态。不同客户端可使用不同数据库布局、索引、缓存与修剪策略， 仍对同一个协议状态达成一致。
“ETH 就是一份特殊的 ERC-20 合约。”
ETH 是协议原生资产，余额与费用处理属于以太坊状态转换规则。 WETH 才是把 ETH 包装成 ERC-20 接口的合约资产；两者不能混为一谈。
“只要区块最终确认，应用层结果就一定安全。”
最终确认强化历史稳定性，不会替合约做安全审计，也不会判断交易是否符合用户真实意图。 恶意授权和逻辑漏洞可以被协议正确、确定地执行。
“一台计算机”指的是一份规范的逻辑状态与一套状态转换规则； “遍布全球”指的是许多独立运营者持有副本并验证转换。 统一的是协议结果，不是硬件、软件语言或运营主体。
09 · Recap
把整课压缩成一条因果链
如果你能不看正文讲清这条链，以太坊整体架构已经立住了。
- 01
Ethereum 不等于 ETH。前者是网络与协议体系，后者是原生资产。
- 02
主网不是主服务器。它是许多独立节点共同运行的公共生产网络。
- 03
执行层判断状态转换是否有效。EVM 是其中执行字节码的确定性规则环境。
- 04
共识层在有效候选中推进规范历史。有效性与规范性是两道门。
- 05
合约不会自己运行。签名交易或其他合约调用才会触发代码。
- 06
节点不下载一个权威答案。完整执行节点本地重放，再核对根承诺。
- 07
全球计算机是一台逻辑状态机。同一起点、同一有序输入、同一规则产生同一结果。
现在检查你的理解
1. “以太坊主网”最准确指什么？
2. 两笔有效交易换序后结果不同，是否违反确定性？
3. 谁直接重执行合约字节码并计算 post-state？
4. 一份拍卖合约如何在截止后结算？
5. 节点重放区块后算出的 stateRoot 与区块承诺不同，应当怎样？
6. 区块达到最终性，能证明什么？
10 · Sources
术语与一手资料
本课刻意停在架构层；后面的专章会继续拆解 EVM、合约、PoS 与状态树。
核心术语
世界状态 WORLD STATE
执行层当前所有账户状态的逻辑集合，包括余额、nonce、代码与存储等；它不等于共识层 BeaconState。
状态转换 STATE TRANSITION
按照协议规则，从旧状态和有序交易输入计算新状态的过程。
状态根 STATE ROOT
对执行层世界状态的紧凑密码学承诺。节点可通过本地执行核对区块承诺是否一致。
执行载荷 EXECUTION PAYLOAD
共识区块中承载执行层数据的部分，包含有序交易及执行结果相关字段。
规范链 CANONICAL CHAIN
节点按共识规则当前认可的链历史；执行有效是候选进入这条历史的必要条件，但不是唯一条件。
最终性 FINALITY
PoS 共识中的强确认属性，使已最终确认的历史若要回滚会付出显著经济代价。
Engine API ENGINE API
同一节点上的共识客户端与执行客户端交换执行载荷、有效性与链头指令的本地接口。
确定性 DETERMINISM
同一起点、同一有序输入、同一协议规则必须得到同一结果；它不意味着换序后结果仍相同。
官方一手资料
-
01
ethereum.org — Technical intro to Ethereum Ethereum、ETH、EVM、节点与“单一规范计算机”这一逻辑抽象的官方入门。
-
02
ethereum.org — Node architecture 执行客户端、共识客户端、验证者与 Engine API 的职责边界。
-
03
ethereum.org — Ethereum Virtual Machine 分布式状态机、状态转换函数、EVM 执行环境与持久存储。
-
04
ethereum.org — Introduction to smart contracts 智能合约作为位于链上地址的代码与状态，以及被交易调用的执行模型。
-
05
Ethereum Execution Layer Specification 以可执行 Python 规格描述当前执行层分叉规则与状态转换。
-
06
Ethereum Consensus Specifications PoS 共识状态转换、分叉选择、证明、检查点与最终性的规范来源。
-
07
Ethereum Execution APIs — Engine API 共识客户端与执行客户端协作所用 Engine API 的版本化规范。
现在先回到本课因果链。第 8 章再深入 Stack、Memory、Storage 与 Opcode； 第 9 章拆智能合约生命周期；第 10 章拆 PoS；第 11 章拆世界状态与 trie。 不必在地图课里一次吃完所有实现细节。