全网为何算出同一个答案？

更准确地说，以太坊是一台逻辑上单例、物理上多副本的确定性状态机： 全球各地的完整执行节点，从同一父状态开始，按同一顺序执行同一批交易，并用状态根核对结果； 共识层再决定哪一串有效状态转换成为规范链，并最终确定。

要让“多台机器看起来像一台逻辑计算机”，至少需要四样东西：

1. 共同起点：节点认可同一个父块和父状态承诺。
2. 共同输入：区块给出同一批、严格有序的交易与区块上下文。
3. 共同规则：客户端按同一协议分叉版本、Gas 和回滚规则运行 EVM。
4. 共同历史：共识从多个有效候选中选出规范链，并逐步把检查点最终确定。

把比特币类比成公开账本很自然：交易改变余额归属。以太坊保留了账本能力， 又加入可编程状态——账户余额、合约代码、合约存储都能按统一规则改变。

“状态机”并不神秘。它只是一套把旧状态和输入转换成 新状态的规则。自动售货机也是状态机：当前库存与投入硬币是输入，规则决定出货、 找零和新库存。以太坊把这个模型扩展到全球网络，并用密码学签名、Gas、区块和共识来限制谁能发指令、 指令如何执行、结果如何验证。

入门公式很干净，但真实区块执行还需要更多共同输入：

执行层世界状态可以想成一张巨大的映射表：每个地址对应一条账户记录。 账户记录包含 nonce、余额、代码哈希和存储根；合约的具体持久数据位于自己的 storage trie 中。

区块不会把整个世界状态复制一遍。执行客户端在自己的数据库中维护状态； execution payload 里的 state_root 承诺执行完该块后应得到的状态。 任何余额、nonce、代码或存储槽发生变化，都会沿哈希路径传播，通常得到不同的根。

开发者把 Solidity 等语言编译成 EVM 字节码，再通过交易部署。部署完成后，运行时代码与账户关联； 后续交易可以携带 calldata 调用函数，函数还可向其他合约发送内部消息调用。

1. 代码：定义允许哪些状态转换，例如“只有余额足够才能转出代币”。
2. storage：保存跨交易存在的数据，例如余额表、所有者和计数器。
3. memory 与 stack：只在一次调用执行期间存在，结束后不会写入世界状态。
4. Gas：为每条操作计量资源，限制无限循环与网络滥用。
5. 调用者与区块上下文：签名者、msg.sender、value、时间戳等成为共同输入。

合约也不会自行“定时运行”。如果需要在某个条件满足时执行，仍要有人或自动化服务提交交易。 以太坊保证的是：一旦这笔交易进入候选区块，所有验证它的完整执行节点都按相同规则处理。

先记住一个关键边界：签名交易只是请求。它进入某个节点的交易池，甚至传遍网络， 都不等于已经改变规范状态。状态只会随被接受的区块转换。

完整流程拆解

1. 钱包签名：私钥只用于签名，不会发送给网络。nonce 让来自同一账户的交易有顺序，并防止重复执行。
2. RPC 与 mempool：钱包通常把交易交给某个执行客户端；客户端做基础检查后放入自己的本地交易池，并通过执行层 P2P 网络传播。
3. 提议候选块：当前 slot 的提议者确定父块；其执行客户端或外部 builder 选择并排序交易，执行后生成 execution payload。
4. 广播 Beacon Block：提议者的共识客户端把 execution payload 放入信标块，验证者签名并在共识网络广播。
5. 其他节点复算：共识客户端核验共识字段，再通过 Engine API 让本机执行客户端重放交易、计算状态根和收据根。
6. 证明与最终性：验证者只应为有效链头发出 attestation；分叉选择决定当前 head，检查点投票逐步带来最终性。

Geth 用 Go 编写，Besu 用 Java，Nethermind 用 C#，Reth 用 Rust。它们的内部结构可以不同， 但处理同一个有效区块时必须得到同一个协议结果，否则至少有一个实现存在缺陷或使用了错误规则。

确定性需要把所有会影响结果的东西都变成共同输入或固定规则：

1. 字节必须相同：签名交易的字段、calldata 与访问列表不能各自解释。
2. 顺序必须相同：tx₁ 的输出可能成为 tx₂ 的输入；交换顺序可能改变余额、价格或成功与否。
3. 上下文必须相同：时间戳、base fee、区块号、prevRandao 等来自候选区块，而非节点本机。
4. 异常必须相同：out-of-gas、revert、无效 opcode、调用深度与退款规则都由协议定义。
5. 分叉版本必须相同：网络升级会改变规则；客户端必须在同一激活条件切换。

一个完整节点内部发生了什么

合并后的普通完整节点通常需要一个执行客户端和一个共识客户端。共识客户端收到 Beacon Block， 检查 slot、父块、提议者签名等共识字段；再把 execution payload 交给执行客户端。执行客户端从已知父状态重放交易， 检查 state_root、receipts_root、Gas 等是否一致，并向共识客户端报告 payload 是否有效。

两位提议者、传播延迟或临时网络分区都可能造成短时分叉。节点在同一时刻看到不同链头并不违反确定性： 它们面对的是不同父块或不同交易顺序，也就是不同输入。

可以把确定性与共识画成一个二维表：

最容易误解“全球计算机”的地方，是以为全球节点把一项大任务拆开并行，所以节点越多，合约就跑得越快。 实际上，验证新区块的完整执行节点主要在重复相同计算。

如果代币、交易所、借贷协议和 NFT 市场都能按同一套寻址与调用规则访问彼此， 开发者就不必先向每家公司申请数据库权限。一个合约可以在同一笔交易中调用另一个合约， 继续调用第三个合约，并把所有结果合并成一次状态转换。

这种“共享内存式”组合体验是以太坊应用生态的核心：合约地址、代码和状态公开可发现，调用规则统一， 交易具备原子性。但要注意，顶层交易如果执行失败，合约内部状态修改通常回滚， 发送者 nonce 仍会消耗，Gas 费用仍会支付，并产生失败收据。

如果一项任务只需要一家公司内部完成，或者输入必须保密、数据巨大、计算昂贵，把它交给每个完整节点重复执行通常不合理。 “能写成合约”与“应该写在 L1”是两回事。

Layer 2 如何改变“全球计算机”

Rollup 把大量交易执行移到 L2，再把数据、状态承诺和欺诈证明或有效性证明相关材料提交到以太坊。 因此现代的更好心智模型是：L1 作为全球可验证的结算与数据可用性底座，L2 承担更多应用执行。 以太坊 L1 完整节点并不会逐笔执行所有 L2 内部交易；它们验证 L1 上定义的结算规则与提交内容。

1. 01

   以太坊是逻辑上单例、物理上多副本的确定性状态机。

2. 02

   世界状态包含账户 nonce、余额、代码与合约 storage；执行状态根对它作密码学承诺。

3. 03

   交易是带签名的状态修改请求，进入 mempool 并不等于已经改变规范状态。

4. 04

   区块把交易顺序与上下文固定下来，完整执行节点才能从同一父状态重算同一结果。

5. 05

   不同客户端实现必须遵循同一协议语义；本地结果不匹配就应拒绝 payload。

6. 06

   执行层判断状态转换是否有效；共识层选择有效候选历史并提供最终性。

7. 07

   节点重复计算换来独立验证、抗篡改和韧性，也带来吞吐、费用、公开性与资源边界。

8. 08

   Layer 2 把更多执行移出 L1，再利用以太坊作为可验证的结算、安全或数据底座。

理解检查

State machine

根据当前状态、输入和规则产生新状态的系统。

World state

执行层地址到账户记录的映射，以及账户所承诺的合约持久存储。

State transition

交易与协议操作按顺序把旧状态变成新状态的过程。

EVM

执行客户端中的协议虚拟机，解释字节码、计量 Gas 并实现调用与回滚规则。

State root

对某一时刻完整状态的密码学承诺；本课主要指 execution payload 的执行状态根。

Execution payload

Beacon Block 中承载有序交易、执行区块字段和执行后承诺的部分。

Execution client · EL

管理交易池、运行 EVM、维护执行状态、构建或重算 payload 的客户端。

Consensus client · CL

处理 Beacon Block、attestation、分叉选择与最终性的客户端。

Engine API

本机 EL 与 CL 交换 payload 构建、有效性和 head / safe / finalized 信息的认证接口。

Canonical chain

分叉选择当前认定应跟随的规范历史；它可在最终确定前发生短时重组。

Finality

检查点得到足够质押权重支持后的强经济终局性。

Determinism

相同前状态、交易顺序、区块上下文和协议规则产生相同结果。

官方资料

1. 01
   ethereum.org · Technical intro to Ethereum 以太坊、EVM、状态和智能合约的官方技术导论。
2. 02
   ethereum.org · Ethereum Virtual Machine 分布式状态机、状态转换函数、EVM 栈与执行上下文。
3. 03
   ethereum.org · Transactions 交易字段、签名消息、合约调用与交易生命周期。
4. 04
   ethereum.org · Blocks Beacon Block、execution payload、执行重放与区块字段。
5. 05
   ethereum.org · Accounts nonce、余额、codeHash、storageRoot 与账户状态结构。
6. 06
   ethereum.org · Introduction to smart contracts 智能合约的部署、调用、组合性与链外数据边界。
7. 07
   ethereum.org · Nodes and clients 执行客户端、共识客户端、完整节点、轻节点和归档节点。
8. 08
   ethereum.org · Node architecture 合并后的 EL、CL、验证者客户端与 Engine API 架构。
9. 09
   ethereum.org · Gasper LMD-GHOST 分叉选择、Casper FFG、justification 与 finalization。
10. 10
    ethereum.org · Merkle Patricia Trie 执行状态、交易与收据如何通过根哈希承诺。
11. 11
    Ethereum Execution Layer Specifications 当前执行层协议的可读 Python 规范与网络升级定义。
12. 12
    Ethereum Consensus Specs · Bellatrix Beacon Chain execution payload 验证、执行引擎接口与 BeaconState 转换规范。