01 · Orientation
先把“发生”拆成五件事
看到交易哈希、看到 pending、看到区块、看到 success、看到 finalized，分别在回答不同的问题。
以太坊交易是一条由外部账户发起、希望改变网络状态的已签名指令。最简单的是转移 ETH；更常见的是调用合约。两者走同一条主干流程，但执行内容不同。
Accepted
某个节点接受了吗？
只说明签名字节通过了这个节点此刻的协议检查与本地策略，可能进入它自己的交易池。
Included
进入某个区块了吗？
有区块号、区块哈希与交易索引，说明它进入了当前规范链的一个候选历史。
Executed
顶层执行成功了吗？
收据 status=1 表示成功；status=0 表示已上链但顶层执行失败。
Finalized
历史最终确定了吗？
区块成为 finalized 后，推翻它需要严重的共识失败与大规模质押罚没。
本课采用哪一种交易？
主线采用“普通 EOA 发起的 EIP-1559 Type 2 交易”。这能清楚展示签名、nonce、费用、交易池与区块执行。当前主网也存在 EIP-7702 Type 4；ERC-4337 的 UserOperation 则先走替代交易池与 bundler。它们不是本课主线，不能把所有钱包动作都硬套成完全相同的路径。
02 · Wallet
钱包先准备，再请你授权
“点击确认”之前，钱包通常已经询问节点、构造字段并做过模拟；签名只证明授权，不保证未来成功。
钱包不是区块链本身。它是账户控制与交易构造界面：从 RPC 节点读取链的当前视图，形成待签名载荷，再让本地密钥或硬件设备签名。
- 读取环境
- 确认
chainId、发送账户当前/待处理 nonce、余额、base fee 与费用建议。 - 形成意图
- 确定
to、value与data。合约交互的真正动作往往藏在 calldata 中。 - 估算资源
eth_estimateGas在某个状态快照上模拟；之后状态、价格或排序改变，真实结果仍可能不同。- 展示确认
- 钱包把机器字段翻译成人类界面。你看到的是解释层，签名覆盖的是规范编码后的字节。
两个哈希，不要混成一个
Signing hash · 签名哈希
对“尚未加入签名值”的规范载荷求哈希。私钥对它产生 yParity / r / s。
keccak256(0x02 || rlp(unsigned fields))
Transaction hash · 交易哈希
对完整已签名交易编码求哈希。钱包、节点与浏览器用它定位同一组字节。
keccak256(signed transaction bytes)
03 · Lifecycle
亲手走完七个阶段
选择阶段，观察“谁在行动、产生了什么证据、此刻还不能断言什么”。
交易旅程显微镜
演示数据不会连接钱包或网络；全部状态都在本页本地切换。
Actor · wallet / signer
密钥对明确字段作出授权
自托管钱包通常在本地软件或硬件设备内签名。私钥不需要、也不应该发给 RPC 节点。
已签名交易字节；可恢复发送者并检查字段完整性。
Actor · wallet → one node
先把字节交给一个执行节点
常见入口是 eth_sendRawTransaction。钱包并非直接连接“全网所有节点”。
RPC 请求已发出；若解码、准入或本地池接纳失败，节点会返回错误，而不是成功哈希。
Actor · execution client
节点初筛，并尝试接纳进自己的交易池
编码、签名、chainId、nonce、余额、intrinsic gas、费用关系与本地池策略都可能让它拒绝。
接纳成功后，RPC 才返回交易哈希；这只说明该节点愿意暂存和传播。
Actor · execution peers
交易在执行层网络逐跳扩散
提交节点向邻居公告哈希或交易；每个邻居取得字节后独立复核，再决定是否放进自己的 txpool 并继续传播。
可见范围扩大，但每个节点的 txpool 仍可能不同。
Actor · local txpool
交易成为“可被挑选的候选”
nonce 连续且当前可执行的交易常被归为 pending；有 nonce 缺口的未来交易可能 queued。
候选不是承诺；可能等待、被替换、逐出或永不包含。
Actor · builder / proposer / clients
排序后逐笔执行，形成 execution payload
交易基于父状态按顺序运行，生成新状态根与收据；提议者把 payload 放进 beacon block。
有 block inclusion 与 receipt；区块仍可能在链头附近重组。
Actor · validator set
复验、投票，让历史获得最终性
其他节点重放 execution payload；验证者对链头与 checkpoint 投票，区块逐步走向 safe 与 finalized。
finalized 区块及其祖先获得加密经济最终性。
当前阶段 01：签名只证明授权与完整性，不证明执行会成功。
04 · Admission
节点为什么接纳，也为什么拒绝
“以太坊规则”与“这个客户端的交易池政策”并不是一回事；入池检查与区块执行也不是一回事。
结构与协议
- 交易类型与编码能否解析
- chainId 与当前网络是否匹配
- 签名是否规范、发送者能否恢复
- intrinsic gas 与费用字段关系是否合法
- 是否符合当前协议升级规则
当前状态
- nonce 是否已过期，或是否存在未来缺口
- 余额能否覆盖 value 与费用最坏上限
- 发送者在当前规则下是否可发起
- 同 nonce 是否已有另一候选
- 区块纳入时还会按新状态重新检查
本地政策
- 最低 priority fee / tip 门槛
- 每账户与全池容量
- 允许的 nonce gap
- 同 nonce 替换所需涨幅
- 超时、资源压力与逐出规则
拒绝不是 revert
| 结果 | 是否进入区块 | gas 与 nonce | receipt |
|---|---|---|---|
| 节点预先拒绝 | 否 | 不产生链上费用，不消耗链上 nonce | 无 |
| 已包含但顶层执行失败 | 是 | 消耗 gas，发送者 nonce 已消耗 | status=0 |
| 执行成功 | 是 | 按实际执行消耗 gas，nonce 已消耗 | status=1 |
status=0 不只可能来自 Solidity 的 REVERT，也可能来自 out-of-gas 或 invalid opcode。普通 Type 2 交易顶层失败时，调用产生的持久状态、转账与日志回滚，但已经支付的 gas 与发送者 nonce 不回滚。内部调用若失败后被外层合约捕获，顶层交易仍可能是 status=1。
05 · Propagation
没有一个“云端总候车室”
交易池不是共识状态。它是每个执行节点为了传播与构建区块维护的本地工作集。
不存在一个“全网统一交易池”。节点的连接对象、接收时刻、容量、最低费用、nonce 政策与逐出规则不同，因此同一时刻看到的候选集合也不同。
Execution node A
nonce 42 · our tx
nonce 17 · tx β
nonce gap · tx γ
Execution node B
nonce 42 · our tx
nonce 44 · future tx
private relay copy
Execution node C
our tx absent
replacement nonce 42
low current eligibility
pending 与 queued 是节点视角
- pending
- 以 Geth 语境为例，通常是按这个节点当前状态可执行、nonce 连续的交易；不代表下一块保证包含。浏览器也常把“未确认”笼统称为 pending。
- queued
- 节点暂时不能顺序执行的未来交易，常见原因是 nonce 缺口。分类与保留时间是客户端实现细节。
- replacement
- 同一发送者、同一 nonce 的另一笔交易，满足这个节点的费用涨幅政策后可替换本地旧候选。
- dropped / evicted
- 某节点因容量、超时、替换或状态变化移除交易；别的节点仍可能保存甚至包含它。
06 · Architecture
交易与区块，走两张网络
执行客户端传播交易并运行 EVM；共识客户端传播 beacon block 与投票。它们在同一节点内通过 Engine API 协作。
Execution layer network
传播交易，验证状态转换
执行层 peer-to-peer 网络交换待处理交易。执行客户端维护本地 txpool、运行 EVM、计算状态根与 receipt。
Consensus layer network
传播区块，对顺序投票
共识层 gossip 传播 beacon block、attestations 等。共识客户端检查 slot、提议者、父块与 fork choice。
出块时，两个客户端怎样交接？
- 共识协议已为 slot 确定提议者职责；Fusaka 后的 proposer lookahead 让未来安排更明确，不是 slot 到来才临时“抽签”。
- 提议节点的共识客户端请求一个 execution payload；它可能来自本地执行客户端，也可能经链下 builder / relay 路径取得。
- payload 包含一组已排序交易及执行结果承诺。共识客户端把它嵌入并签名 beacon block。
- 其他节点收到区块后，共识层检查元数据，执行层按该顺序重放交易并核对状态根。
07 · Execution
打包不是装箱，而是先算出结果
区块中的交易有严格顺序。第 n 笔看到的是前 n−1 笔已经产生的新状态，因此调换顺序可能改变结果。
每 12 秒是一个 slot，也就是一次提议区块的机会；一个 slot 不保证一定出现区块。提议者离线、网络延迟或其他故障都可能让 slot 被错过。
账户余额、nonce、合约代码与 storage 构成执行起点。
它的写入会成为后续交易看到的新事实。
扣除费用、推进 nonce，转账或运行合约代码。
state root、receipts root、gas used 等进入 payload 承诺。
为什么不能简单说“按 gas price 从高到低”？
协议没有规定统一 FIFO 或单纯价格排序。构建者会考虑当前 effective tip、同账户 nonce 依赖、剩余 block gas、MEV、私有 bundle 与自身策略。无论排序如何，最终 payload 必须能从父状态确定性重放，并满足区块规则。
effectiveGasPrice = 18 + min(1.5, 32 − 18) = 19.5 gwei
普通转账 gasUsed = 21,000 → 实际执行费 = 21,000 × 19.5 gwei = 0.0004095 ETH
gasLimit × maxFeePerGas 更接近签名者愿意承担的费用上限与余额准入预算，不是默认实际账单。Type 2 的 base fee 被销毁，priority fee 进入 execution fee recipient。
收据证明了什么？
- status
- 0x1 · top-level success
- blockNumber
- 0x… · 已包含
- transactionIndex
- 0x2a · 区块内顺序
- gasUsed
- 0x5208 · 21,000
- effectiveGasPrice
- 0x… · 实际每 gas 价格
- logs
- [] · 本例无事件日志
receipt 是“已进入某区块并执行”的结构化结果，不保存合约函数返回值，也不等于协议最终性。查询尚未包含的交易时，eth_getTransactionReceipt 通常返回 null。
08 · Consensus
“确认”不是一个瞬间
从进入链头到 finalized，信心逐层增强。应用显示的 confirmations 只是后继区块计数，不等于 PoS 最终性。
其他节点收到 beacon block 后，不是相信提议者的计算结果，而是让自己的执行客户端重放交易，并检查 state root、receipts root 与 gas 等是否一致。共识客户端同时检查提议者、slot、父块、签名与 fork choice。
block inclusion
交易出现在某个有效区块并有 receipt。它可能尚未成为大多数节点眼中的规范链头。
head / latest
fork choice 当前选择了包含它的分支。链头附近仍可能因传播差异或竞争区块发生重组。
justified / safe
获得更强的验证者投票或 safe-head 保证。safe 强于 latest、弱于 finalized；不要硬换算为固定确认数。
finalized
checkpoint 及其祖先最终确定。制造冲突最终性会让至少约三分之一总质押面临罚没。
block inclusion → head → justified → finalized
为什么通常要跨越 epoch？
一个 epoch 有 32 个 slot，约 6.4 分钟。活跃验证者在每个 epoch 内完成投票；当代表至少三分之二总质押的投票形成 successive checkpoint 的 supermajority link，较新的 checkpoint 可 justified，较早者可 finalized。因此健康网络下常说最终性大约需要十几分钟，但这不是服务等级保证：若足够多验证者离线，链可能继续出块却暂时停止最终化。
09 · Explorer
浏览器页面应该按什么顺序读？
先判断是否包含与顶层结果，再核对意图、费用和最终性；不要只看绿色图标。
确认你跟踪的是同一组已签名字节；哈希本身不表示成功。
pending 通常没有 block number；有 receipt 才说明已经包含。核对区块是否仍在规范链。
发送者由签名恢复；to 若是合约，value 只是随调用发送的 ETH，不是全部动作。
同一发送账户的顺序坐标。相同 nonce 的不同哈希通常意味着替换竞争。
浏览器的函数名来自 ABI 或启发式解释；真正执行的是 calldata 字节。
这是普通执行 gas 账单的核心；gas limit 与 max fee 是上限，不应直接当实际支出。
成功执行时合约可发出事件。日志是索引线索，不等于合约所有状态变化。
确认页面是在显示 confirmations、safe 还是 finalized；这些概念不能互换。
10 · Diagnosis
它究竟卡在哪一层？
选择你观察到的症状。诊断首先区分：是否有哈希、是否有 receipt、是否存在同 nonce 竞争、区块是否仍在规范链。
交易命运诊断器
它提供协议层排查顺序，不替代具体钱包或 RPC 的错误信息。
预先拒绝
从错误文本检查编码/签名、chainId、nonce too low、余额、intrinsic gas、费用关系与本地最低政策。没有 receipt 就没有链上 gas 与 nonce 消耗。
仍是本地候选
检查当前 base fee 是否高于 max fee、priority fee 是否缺乏竞争力、nonce 前序是否已完成，以及交易是否只停留在少量节点。
nonce 缺口
同一账户必须按 nonce 顺序执行。较早 nonce 未包含时，较晚交易即使费用高也通常只能等待；先定位最小缺口。
本地替换竞争
相同发送者与 nonce 的另一笔交易被某节点接纳。比较两笔费用与传播范围；旧交易并未从全网被“删除”。
局部逐出或过期
某 RPC 查不到不等于所有节点都没有。检查其他可信节点与链上 nonce；贸然重发相同意图前，先排除原交易仍会被包含的可能。
有效但执行失败
交易已经上链、nonce 已消耗且要支付 gas。结合 trace、revert data 与调用前状态定位合约条件；提高费用通常不能修复逻辑失败。
链头重组
原区块离开规范链。交易可能重新 pending、在另一块出现或因新状态失效；以当前规范链 receipt 与 finality 为准。
当前判断：节点在入池前拒绝；先读 RPC 错误，不要把它当作链上 revert。
11 · Recap
把整课压缩成一条责任链
钱包负责表达与授权；执行节点负责传播和计算；共识验证者负责顺序与最终性；你负责不要把中间状态误认成终点。
意图 → 构造 → 签名 → 单节点提交请求 → 初筛并接纳本地 txpool → 返回 tx hash → 执行层 gossip → 各 peer 复核并入各自 txpool → payload 构建 → 区块提议 → 全网重放 → attestation → finalized
十个必须拆掉的误区
自托管主线只提交已签名字节；私钥留在本地或硬件签名环境。
签名证明授权与字段完整性，不预测合约状态或排序。
哈希是标识；receipt 才说明包含和顶层执行结果。
每个执行节点维护自己的局部候选集合。
准入以结构、状态与政策检查为主；模拟也不是未来保证。
排序还受 effective tip、nonce、MEV、bundle 与 builder 策略影响。
12 秒是 slot 时长；slot 是机会，可以错过。
已包含失败交易仍消耗 gas，发送者 nonce 仍推进。
确认数是应用惯例；PoS finality 由 checkpoint 投票形成。
它们按区块给定顺序重放，核对执行承诺是否一致。
六题校准
1. eth_sendRawTransaction 返回交易哈希，最准确的含义是？
请选择一个答案。
2. 哪项最准确地描述 mempool / txpool？
请选择一个答案。
3. nonce 44 的交易为何可能等待 nonce 42、43？
请选择一个答案。
4. 已包含交易的 receipt 为 status=0，哪项正确？
请选择一个答案。
5. 其他节点怎样检查提议区块里的 execution payload？
请选择一个答案。
6. 为什么 confirmations 不能直接等同于 finalized？
请选择一个答案。
尚未作答。完成六题后，用自己的话复述“哈希、receipt 与 finality 各证明什么”。
12 · Reference
术语与一手资料
以 2026 年 7 月已激活的 Fusaka 主网规则为基线；协议仍会升级，遇到精确边界应回到规范。
核心术语
raw transaction · 原始已签名交易
按交易类型编码、包含签名值的字节序列，可通过 eth_sendRawTransaction 提交。
transaction hash · 交易哈希
完整已签名交易字节的 Keccak-256 摘要，用作稳定标识；它不是成功或最终性证明。
txpool / mempool · 交易池
执行节点维护的本地待处理交易集合，不进入共识状态，也不要求不同节点完全一致。
execution payload · 执行载荷
嵌入 beacon block 的执行层区块内容，包含交易序列和执行结果承诺。
receipt · 交易收据
交易被包含后的执行摘要，包括 status、gasUsed、logs、blockHash 与 transactionIndex 等。
attestation · 见证投票
验证者对其所见链头与 checkpoint 关系签名投票，服务于 fork choice 与最终性。
reorg · 链重组
fork choice 改选另一分支，使链头附近部分区块离开规范链；未 finalized 交易结果可能随之变化。
finality · 最终性
区块成为 finalized checkpoint 或其祖先后获得的加密经济保证；推翻需要严重共识故障与质押罚没。
官方与规范资料
-
ethereum.org · Transactions
交易字段、签名、交易生命周期与 typed transaction 总览。
-
ethereum.org · JSON-RPC API
eth_sendRawTransaction、receipt 查询与 latest / safe / finalized 标签。 -
Ethereum Execution APIs · eth_getTransactionReceipt
收据字段、status、effectiveGasPrice 与未找到时的返回边界。
-
ethereum.org · Networking layer
执行层交易 gossip、共识层区块 gossip 与 Engine API 协作。
-
ethereum.org · Block proposal
slot、区块提议、execution payload 与接收节点复验。
-
ethereum.org · Attestations
验证者投票的组成、传播与 checkpoint 作用。
-
ethereum.org · Gasper and finality
justified、finalized、两阶段升级与 LMD-GHOST fork choice。
-
EIP-2718 · Typed Transaction Envelope
交易类型前缀与 payload / receipt envelope。
-
EIP-1559 · Fee market change
Type 2 字段、签名哈希、base fee 与 priority fee 规则。
-
EIP-658 · Receipt status code
receipt 中
status=0/1的协议来源。 -
Geth · txpool namespace
pending、queued 与同账户同 nonce 多候选的客户端视图。
-
ethereum.org · Fusaka
2025-12 激活的 Fulu / Osaka 升级、proposer lookahead 与交易 gas cap。
-
EIP-7825 · Transaction Gas Limit Cap
Fusaka 后单笔交易
2²⁴gas 上限。 -
EIP-7702 · Set EOA account code
Type 4 交易的现代边界；其失败回滚语义不能与普通 Type 2 完全混同。
-
EIP-4337 · Account abstraction
UserOperation、替代 mempool 与 bundler 流程的规范入口。