区块链核心知识点梳理（面试高频考点4）-以太坊交易全流程

提示：文章写完后，目录可以自动生成，如何生成可参考右边的帮助文档

文章目录

• [4. 以太坊交易全流程](#4. 以太坊交易全流程)
• • [4.1 交易生命周期概览](#4.1 交易生命周期概览)
  • [4.2 阶段一：创建交易](#4.2 阶段一：创建交易)
  • • [4.2.1 交易对象构建](#4.2.1 交易对象构建)
    • [4.2.2 交易序列化（RLP编码）](#4.2.2 交易序列化（RLP编码）)
  • [4.3 阶段二：Gas 估算](#4.3 阶段二：Gas 估算)
  • • [4.3.1 为什么需要 Gas 估算？](#4.3.1 为什么需要 Gas 估算？)
    • [4.3.2 Gas 估算方法方法](#4.3.2 Gas 估算方法方法)
  • [4.4 阶段三：交易签名](#4.4 阶段三：交易签名)
  • • [4.4.1 签名原理](#4.4.1 签名原理)
    • [4.4.2 签名过程详解](#4.4.2 签名过程详解)
    • [4.4.3 签名安全性](#4.4.3 签名安全性)
  • [4.5 阶段四：交易广播](#4.5 阶段四：交易广播)
  • • [4.5.1 P2P 网络传播](#4.5.1 P2P 网络传播)
    • [4.5.2 节点验证规则](#4.5.2 节点验证规则)
  • [4.6 阶段五：内存池（Mempool）](#4.6 阶段五：内存池（Mempool）)
  • • [4.6.1 内存池结构](#4.6.1 内存池结构)
    • [4.6.2 交易排序策略](#4.6.2 交易排序策略)
    • [4.6.3 内存池监控](#4.6.3 内存池监控)
  • [4.7 阶段六：交易打包与执行](#4.7 阶段六：交易打包与执行)
  • • [4.7.1 区块构建流程](#4.7.1 区块构建流程)
    • [4.7.2 EVM 执行过程](#4.7.2 EVM 执行过程)
    • [4.7.3 交易执行示例](#4.7.3 交易执行示例)
  • [4.8 阶段七：区块确认](#4.8 阶段七：区块确认)
  • • [4.8.1 确认机制（POS）](#4.8.1 确认机制（POS）)
    • [4.8.2 区块重组（Reorg）](#4.8.2 区块重组（Reorg）)
  • [4.9 完整流程时间线](#4.9 完整流程时间线)

---

4. 以太坊交易全流程

4.1 交易生命周期概览

4.2 阶段一：创建交易

4.2.1 交易对象构建

以太坊有两种交易类型（EIP-1559后）：

交易类型对比：

4.2.2 交易序列化（RLP编码）

以太坊使用 RLP（Recursive Length Prefix） 编码：

4.3 阶段二：Gas 估算

4.3.1 为什么需要 Gas 估算？

4.3.2 Gas 估算方法方法

1: 使用 eth_estimateGas RPC

方法 2: 链下模拟执行

Gas 估算注意事项：

1. 状态依赖性
   
2. 时间延迟问题

时间 T0: 估算 Gas → 50,000

时间 T1 (+10分钟): 链上状态已变化

时间 T2: 交易执行 → 实际需要 65,000

结果: Out of Gas

解决方案: 设置较大的 gasLimit 缓冲

3. 合约内部调用
   

4.4 阶段三：交易签名

4.4.1 签名原理

以太坊使用 ECDSA（椭圆曲线数字签名算法）：

4.4.2 签名过程详解

步骤 1: 计算交易哈希

步骤 2: ECDSA 签名

步骤 3: 签名验证（节点侧）

4.4.3 签名安全性

常见攻击与防护：

1. 重放攻击（Replay Attack）

问题: 攻击者复制已签名交易，在其他链上重放示例:

• 以太坊主网交易 → 被重放到 BSC
• 用户资产被盗

解决方案: EIP-155 引入 chainId

• 签名包含 chainId
• 不同链的签名不兼容

2. Nonce 重用攻击

问题: 如果 k 值重用，攻击者可计算出私钥

公式: s1 - s2 = k^(-1) * r * (pk - pk) = 0→ 可解出 private_key

防护: 每次签名必须使用新的随机 k

3. 低 s 值攻击

问题: 对于同一交易，存在两个有效签名 (r, s) 和 (r, -s)

防护: EIP-2 要求 s 值必须 ≤ secp256k1.n/2

4.5 阶段四：交易广播

4.5.1 P2P 网络传播

4.5.2 节点验证规则

验证失败常见原因：

4.6 阶段五：内存池（Mempool）

4.6.1 内存池结构

4.6.2 交易排序策略

Geth 的排序算法（简化）：

4.6.3 内存池监控

开发者可以监控内存池状态：

4.7 阶段六：交易打包与执行

4.7.1 区块构建流程

4.7.2 EVM 执行过程

4.7.3 交易执行示例

场景：

Alice 调用 Uniswap 交换 1 ETH → USDC

交易收据（Receipt）：

4.8 阶段七：区块确认

4.8.1 确认机制（POS）

确认次数建议：

4.8.2 区块重组（Reorg）

重组场景：

时间线:

T0: 验证者A 和 验证者B 同时生成区块101

T1: 部分节点收到 101a，部分收到 101b

T2: 验证者C 在 101b 上构建 102b（权重更高）

T3: 网络达成共识，101a 被丢弃

影响:

• 区块101a 中的交易需要重新打包
• 用户交易可能从"已确认"变为"待处理"
• 防护: 等待多次确认

4.9 完整流程时间线

总耗时分析：

• 快速确认：~34 秒（1 确认）
• 安全确认：~70 秒（3 确认）
• 最终确定：~13 分钟（Finality）