W3
技术原理中级预计 30-40 分钟9 个步骤42 次学习

账本与交易的技术实现

把「一笔交易到底发生了什么」拆到最底层:先用表格对比 UTXO 与账户模型两种账本,再逐步跟踪交易从签名、广播、内存池、打包到确认的完整生命周期,讲透 Nonce 与交易顺序、EIP-1559 前后的 Gas 费用模型、世界状态与状态根、EVM 的三种数据位置成本差异、节点同步方式与数据可用性,最后读懂交易回执与事件日志,并带你到 Etherscan 上把每个字段和概念一一对上。

账本与交易的技术实现
⚠️
操作前必读

本章不涉及资金操作,但会解释「交易为什么卡住」「手续费为什么被扣却失败」这类日常问题的根因。请注意三点技术认知:一、链上交易一经广播不可撤销,任何加速或取消都必须用「同 Nonce + 更高手续费」的替换交易实现;二、交易失败(Status = Failed)时已消耗的 Gas 不会退还;三、不要在主网上反复做无意义的转账实验来「验证概念」,用 Sepolia 等测试网加免费测试币即可,成本为零。

01
1. 两种账本模型与交易流程

先分清两种账本模型:UTXO 与账户模型

登录记录进度

比特币使用 UTXO(Unspent Transaction Output,未花费交易输出)模型:链上并不存在「余额」这个字段,你的余额是「一堆属于你的、尚未被花掉的输出」的总和;一笔交易的输入必须是此前某笔交易的输出,且必须整笔花掉,剩余部分作为找零(Change)回到自己的新地址。以太坊使用账户模型(Account Model):每个地址像银行账户一样拥有 balancenoncecodestorage 等字段,交易直接从一个账户扣款、给另一个账户加钱。

对比维度 UTXO(比特币) 账户模型(以太坊)
状态表示 一组未花费输出的集合 一棵全局账户状态树
余额概念 需要自行累加所有属于你的 UTXO 直接读取 balance 字段
并发处理 天然友好,不同 UTXO 互不冲突 同一账户的交易必须串行
隐私性 较好,每次交易可换新地址 较差,地址行为长期累积可被画像
双花防护 输出一旦被引用即失效 依赖 Nonce 顺序约束
智能合约 能力有限,脚本表达力弱 完整支持,可持久化状态
代表项目 比特币、莱特币 以太坊、BNB Chain
先分清两种账本模型:UTXO 与账户模型
先分清两种账本模型:UTXO 与账户模型|界面示意 · ethereum.org · 采集于 2026-09-18
💡
小技巧:

在 Bitcoin 钱包里看到「未花费余额」实际是软件帮你累加的结果;在 Etherscan 上看到的 Balance 则是状态树里的一个真实字段。理解这点,就能解释为什么两条链的手续费与找零逻辑完全不同。

02
1. 两种账本模型与交易流程

跟踪一笔交易的完整生命周期

登录记录进度

一笔链上交易要经过八个阶段:构造(钱包组装收款地址、金额与 Gas 参数)→ 签名(用私钥对交易做数字签名,私钥始终留在本地)→ 广播(把签名后的原始交易发送给至少一个节点)→ 进入内存池(Mempool)(节点本地维护的待打包交易池,按手续费高低排序)→ 被打包(出块者挑选交易组成候选区块)→ 执行(节点按顺序执行交易、修改世界状态)→ 上链(区块被广播并被网络接受为主链)→ 获得确认(后续区块不断叠加,最终性逐步提高)。理解这条链路后,你就能定位卡顿到底发生在哪一环。

跟踪一笔交易的完整生命周期
跟踪一笔交易的完整生命周期|界面示意 · ethereum.org · 采集于 2026-09-18
🚫
避坑提醒:

交易一旦广播就无法撤回,重复广播同一笔交易不会加速,只会造成重复提交与手续费浪费。卡住时的正确做法是用「相同 Nonce + 更高手续费」的替换交易覆盖它。

💡
小技巧:

钱包里显示 Pending 但区块浏览器上查不到,通常说明交易还没被任何节点接受,等待或重新广播即可;反之浏览器上能看到哈希,就说明交易已进入节点视野。

03
1. 两种账本模型与交易流程

掌握 Nonce 与交易顺序

登录记录进度

以太坊中每个账户都有一个从 0 开始单调递增的计数器 Nonce,它记录「这个账户已经发出了多少笔交易」。节点执行交易时要求交易中的 nonce 字段恰好等于该账户当前的 Nonce,执行成功后加一。

这带来两个直接后果:其一,同一账户的多笔交易必须按 Nonce 严格顺序执行,前面一笔卡住时,后面即使手续费再高也无法被处理;其二,可以用 Nonce 做替换——把同一 Nonce、更高 Gas 的版本重新签名广播,网络最终只会确认其中一笔。

所谓的「加速(Speed Up)」与「取消(Cancel,即向自己转 0 并支付高额手续费)」都是这一机制的应用。

掌握 Nonce 与交易顺序
掌握 Nonce 与交易顺序|界面示意 · ethereum.org · 采集于 2026-09-18
🚫
避坑提醒:

切忌随意「跳过」待处理交易的 Nonce:跳号会让后续所有交易一起卡住,直到那个空缺被填补(例如向自己转 0 ETH)。手动修改 Nonce 之前,务必先到区块浏览器上确认该账户真实的 Pending Nonce。

💡
小技巧:

在 MetaMask 的「设置 → 高级 → 自定义交易 Nonce」中开启后即可手动指定 Nonce,这是处理卡单最直接的工具。

04
2. 执行与计费:Gas 与世界状态

理解 Gas 机制与 EIP-1559

登录记录进度

Gas 是链上计算的计量单位。Gas Limit 是你愿意为这笔交易支付的最大 Gas 数量,Gas Used 是实际消耗量,未用完的部分会退还,但交易失败时已消耗的 Gas 不予退还

在 2021 年伦敦升级(EIP-1559)之前,费用模型是单一出价:总费用 = Gas Used × Gas Price。升级后费用被拆为两部分:Base Fee(基础费,由网络依据拥堵程度自动调节并被销毁)+ Priority Fee(优先费,即给验证者的小费),即 总费用 = Gas Used × (Base Fee + Priority Fee);同时为钱包估算引入上限保护,Max FeeMax Priority Fee 共同约束实际成交价 Effective Gas Price

理解 Gas 机制与 EIP-1559
理解 Gas 机制与 EIP-1559|界面示意 · ethereum.org · 采集于 2026-09-18
🚫
避坑提醒:

交易失败(Status = Failed)时同样会扣掉已消耗的全部 Gas。首次与某个陌生合约交互,建议先用区块浏览器上的模拟执行功能预演,或以小额金额试一次,避免 Gas Limit 估算不准造成无谓损耗。

💡
小技巧:

钱包里的「慢 / 一般 / 快」三档只影响 Priority Fee。网络不拥堵时选最低档即可,因为费用大头是自动调节的 Base Fee。

05
2. 执行与计费:Gas 与世界状态

认识世界状态与状态根

登录记录进度

世界状态(World State)是以太坊全部账户当前状态的快照:每个地址的余额、Nonce、合约代码与合约存储内容。这些数据被组织成一棵 Merkle Patricia Trie(默克尔帕特里夏树),树的根哈希称作状态根(State Root),会被写入每个区块头。

于是区块只需给出根哈希,任何轻节点都能借助默克尔证明(Merkle Proof)验证「某个账户此刻余额是多少」,而无需下载全量状态。形式化地,状态转换可写作 σ′ = Υ(σ, T),意思是「旧状态 σ 与交易 T 经过状态转换函数 Υ 得到新状态 σ′」,这是所有 EVM 链执行语义的骨架。

认识世界状态与状态根
认识世界状态与状态根|界面示意 · ethereum.org · 采集于 2026-09-18
🚫
避坑提醒:

状态膨胀(State Bloat)是公链的长期隐患:状态只能不断增长、很难被清理,全节点的磁盘与内存需求持续上升,会逐步抬高运行门槛、削弱去中心化程度。这也是各类「状态过期」「状态租金」提案试图解决的问题。

💡
小技巧:

把「状态根」理解为「整本账的指纹」:指纹一致就说明状态一致。轻钱包、跨链桥、Rollup 的证明系统全都建立在这个指纹之上。

06
2. 执行与计费:Gas 与世界状态

走进以太坊虚拟机(EVM)

登录记录进度

以太坊虚拟机(Ethereum Virtual Machine,EVM)是一个基于栈(Stack)的确定性虚拟机:它不直接执行 Solidity 源码,而是执行编译器产出的字节码(Bytecode),每个字节对应一个操作码(Opcode),例如 PUSH1SLOADSSTORECALL

EVM 提供三个关键数据位置,成本差异巨大:Storage(持久化上链的存储,写入最贵,新写入一个槽位约 20000 Gas)、Memory(单次调用内有效的临时内存,按字节线性计费)、Calldata(外部传入的调用数据,只读,成本最低)。

此外还有操作数栈(最多 1024 层)与代码区(Code)。

走进以太坊虚拟机(EVM)
走进以太坊虚拟机(EVM)|界面示意 · ethereum.org · 采集于 2026-09-18
💡
小技巧:

看懂 SLOADSSTORE 的 Gas 差异,就能明白为什么优秀合约会把循环内的存储读写提到循环外、把常用变量缓存到 Memory 中。

07
3. 节点、日志与动手验证

了解节点如何同步账本与数据可用性

登录记录进度

节点保存账本有三种常见模式:全量同步(Full Sync)从创世块开始逐块执行全部交易,能完整重建状态,但耗时以天计;快照同步(Snap Sync)先下载一份经过验证的状态快照,再补齐最近的区块与状态,速度大幅提升,是以太坊当前主流的同步方式;轻客户端(Light Client)只下载区块头,依赖默克尔证明按需验证账户与交易,适合手机等资源受限场景。另一条重要线索是数据可用性(Data Availability,DA):把交易数据发布到链上、让所有人都能下载并校验,是「任何人可独立验证」的前提,Rollup 正是通过把压缩后的数据发布到 L1 来继承这份保障。

了解节点如何同步账本与数据可用性
了解节点如何同步账本与数据可用性|界面示意 · ethereum.org · 采集于 2026-09-18
💡
小技巧:

自建全节点前先评估「同步时间 + 磁盘容量 + 带宽」三项成本。以太坊全节点目前需要 TB 级存储,并且几乎必须使用 SSD。

08
3. 节点、日志与动手验证

读懂交易回执与事件日志

登录记录进度

交易回执(Transaction Receipt)是节点在交易执行完毕后生成的凭证,关键字段包括:Status(1 表示成功,0 表示失败并回滚,但 Gas 照扣)、Logs事件日志,合约通过 emit 产生的结构化记录,其中 Topic 与 Data 是 DApp 前端查询链上数据的来源)、Gas Used(这笔交易实际消耗的 Gas 量)、Effective Gas Price(实际成交单价,EIP-1559 下等于 Base Fee + Priority Fee)、Cumulative Gas Used(该交易在所属区块内的累计消耗量)。回执是「交易产生了什么后果」的权威记录,比交易本体多出执行结果信息。

读懂交易回执与事件日志
读懂交易回执与事件日志|界面示意 · etherscan.io · 采集于 2026-09-18
💡
小技巧:

DApp 提示「交易成功」但余额没有变化时,多半是合约内部逻辑发生 revert 后被上层捕获。此时到区块浏览器看 Logs 里有没有对应事件,比只看状态更快定位问题。

09
3. 节点、日志与动手验证

动手实践:在 Etherscan 逐项阅读一笔真实交易

登录记录进度

打开 etherscan.io,搜索任意一笔 ERC-20 转账(或从自己钱包的交易记录中复制一个交易哈希),逐项把本章概念对上:Transaction Action 告诉你这是单纯转账还是合约调用;Nonce 对应「这是该账户发出的第几笔交易」;Input Data 点击 Decode Input Data 可看到被调用的函数名与参数,原生转账通常只显示 0xLogs 中的 Transfer 事件记录了 from / to / value;Gas LimitGas Used by TransactionBase FeeMax Priority FeeMax FeeEffective Gas Price 共同还原了真实手续费结构。逐项看完,本章绝大多数抽象概念就落地了。

动手实践:在 Etherscan 逐项阅读一笔真实交易
动手实践:在 Etherscan 逐项阅读一笔真实交易|界面示意 · etherscan.io · 采集于 2026-09-18
🚫
避坑提醒:

不要为了「看懂 Gas」而在主网上反复做无意义的转账实验:链上操作不可逆且每笔都要付费。Etherscan 的交易详情页本身就能满足全部学习需求,必要时再到 Sepolia 测试网用免费测试币演练。

💡
小技巧:

先在 Sepolia 等测试网上用免费测试币完整走一遍同样的流程,把每个字段都看过一遍,再回到主网进行真实操作,学习成本几乎为零。

Etherscan 以太坊区块浏览器

来源与时效

教程记录平台 ethereum.org · 客户端 Web / App · 版本 v1。各平台界面会随版本更新变化,请以官方当前界面为准。

全部步骤已完成

操作完成后建议再核对一次到账金额与手续费,并保留交易哈希作为凭证。

相关教程

共识机制:PoW、PoS 与 BFT
技术原理中级25-35 分钟

共识机制:PoW、PoS 与 BFT

从拜占庭将军问题讲起,说清区块链为什么必须有共识机制:PoW 如何用算力与难调整换来安全,PoS 如何用质押与罚没替换矿工,以太坊的 Gasper 如何把 LMD-GHOST 与 Casper FFG 拼在一起,PBFT 与 Tendermint 代表的三阶段 BFT 有什么取舍。再用一张表格横向对比三种路线的去中心化、能耗、最终性、TPS 与攻击成本,最后落到最终性、软硬分叉、链重组,以及「PoS 是不是更中心化」「Nothing at Stake」两个高频误区。

9 个步骤
技术原理进阶30-40 分钟

MEV 与交易排序:从三明治攻击到 PBS

解释一个普通人本该关心、却常被忽略的事实:<strong>区块空间是稀缺资源,而谁决定交易的先后顺序,就能从中提取价值。</strong> 先用具体数字走完一次三明治攻击的全过程,再梳理 MEV 的几大来源(DEX 套利、清算、抢跑、NFT 抢购),然后把区块生产的产业链摊开——搜索者、构建者、中继、提议者各自拿什么、为什么会有 PBS(提议者与构建者分离)。最后回到用户侧:私有内存池如何避免被夹、滑点设置与三明治的关系、以及为什么「把滑点调到 50% 让交易一定成功」是一个会让你损失更多的选择。

8 个步骤
技术原理进阶30-40 分钟

Intent 与 Solver:从「怎么交易」到「要什么结果」

传统交易要求用户自己说清每一步怎么执行(调用哪个合约、走哪条路径、接受多少滑点);<strong>意图(Intent)</strong>换了个思路:用户只声明想要的结果(例如「用不超过 1000 USDT 换到至少 0.29 ETH」),由一群<strong>求解器(Solver)</strong>竞争去实现它。这一篇讲清意图的生命周期、求解器承担了什么风险、为什么这种结构天然带 MEV 保护、以及订单流拍卖(OFA)与批量拍卖是怎么运作的。同时把新风险摊开:求解器集中化、报价不透明、签名本身就是一个授权范围、失败后无人补偿。最后给出比较不同意图协议的方法,以及使用时的自保清单。

9 个步骤