区块链技术网

编码代理如何重塑工程、产品和设计

Fri, 20 Mar 2026 01:40:35 +0800

软件公司的 EPD (Engineering, Product, and Design) 部门旨在创建优质软件。尽管存在不同的角色，但最终目标是开发出能解决业务问题并可供用户使用的功能性软件。归根结底，这只是一堆代码。认识到 EPD 作为一个职能部门所构建的产出仅仅是代码这一点很重要，因为…… 编码代理（coding agents）突然让代码编写变得异常容易。那么，这会如何改变 EPD 的角色呢？

不断变化的过程：

PRD 已死
瓶颈从实现转移到评审
PRD 万岁

对角色的影响：

通才（Generalists）比以往任何时候都更有价值
编码代理是必需品
好的 PM 很棒，差的 PM 很糟糕
每个人都需要产品感（product sense）
专业化的门槛更高了
你不是建造者就是评审者
每个人都认为他们的角色最受编码代理的优势——而且他们是对的

PRD 已死

PRD (Product Requirement Documents) 在 Claude 时代之前是构建软件的焦点。EPD 流程大体上是：

某人（通常是产品经理）有一个想法
产品经理编写 PRD
设计部门根据 PRD 创建模型
工程部门将模型转化为代码

这并非一成不变的规则（在初创公司，这些步骤会融合在一起，最好的构建者能够同时完成多项工作），但这是教科书式的构建方式。

之所以需要这样做，是因为构建软件（和构建模型）需要大量的时间和精力。因此，为了专注于这些工作而创建了不同的学科。随着人们变得更加专业化，就需要跨学科进行沟通。PRD 是这种沟通的基础，它启动了一切。然后，它会瀑布式（waterfall）地传递给设计部门，设计部门会将优美的文字转化为漂亮的 UI 和流畅的 UX。最后，工程部门会将其变为现实。

编码代理改变了这一切。编码代理可以根据一个想法创建功能性软件。当我和其他人说“PRD 已死”时，我们真正的意思是这种传统的软件构建方式，即从编写 PRD 开始，已经消亡了。

瓶颈从实现转移到评审

现在任何人都可以编写代码，这意味着任何人都可以构建东西。但这并不意味着构建出来的东西架构良好、解决了正确的问题或易于使用。工程、产品和设计部门应该是这些领域的评审者和仲裁者。问题在于，生成的代码并非总是“优秀”的。EPD 的角色变成了评审并确保它是“优秀”的。“优秀”可以意味着以下几点：

从工程系统角度看架构良好：它是以可扩展、高性能、健壮的方式编写的吗？
从产品角度看考虑周全：这解决了用户痛点吗？
设计良好：界面是否易于使用且直观？

由于创建代码初始版本的成本如此之低，我们看到创建了更多的原型。这些原型随后成为焦点，由产品、工程和设计部门进行评审。

问题在于——生成代码太容易了。以前，创建代码需要一段时间——所以作为评审者，你案头需要评审的项目数量有限。然而现在，任何人都可以编写代码。这意味着正在进行的项目数量正在增加。我们已经看到（所有三个职能部门）的瓶颈是评审——获取原型并确保它们是“好的”。

PRD 万岁

Claude 时代之前（以 PRD 开始）的软件构建方式已经消失了。但是，描述产品需求的文档仍然至关重要。

假设某人有一个想法并迅速构建了一个原型。这如何投入生产？它需要由 EPD 的其他成员进行评审。在此过程中，书面文档总是有帮助的，并且通常是必不可少的。当其他人进行评审时，他们如何知道代码的某个部分是偶然存在还是故意为之？这取决于意图。需要对此意图进行某种沟通。

我认为传统的 PRD 流程（PRD → 模型 → 代码）已经消亡了。但描述产品需求的文本却非常有生命力。在将其交付评审之前，这份相关文档应作为原型的必要伴侣。

最标准的格式将是文档，但有一些有趣的想法是共享用于创建此功能的提示（prompts），以此来传达。如果未来的 PRD 只是结构化、版本化的提示（prompts）呢？

通才比以往任何时候都更有价值

我所说的通才（generalists）是指对产品、工程和设计三个领域都有良好理解的人。这些人一直都很有价值且具有影响力——但有了编码代理，他们更是如此。为什么？

沟通是所有事情中最困难的部分。它会减慢速度。一个能够同时进行产品、设计和工程工作的人会比一个三人团队行动更快，因为沟通开销更小。

以前，当实现是障碍时，这个通才（generalist）仍然需要与其他人沟通才能完成工作。现在他们只需要与代理（agents）沟通。这意味着他们自己就能比以往任何时候都产生更大的影响力。

编码代理是必需品

由于编码代理使得实现成本低廉，使用它们是必需的。能够采用编码代理的人将能够独自完成更多工作：

采用编码代理的 PM 可以通过直接构建原型来验证想法，而无需编写规范（spec）和等待
采用编码代理的设计师可以在代码中进行迭代，而不仅仅是在 Figma 中
采用编码代理的工程师可以将时间从实现转移到系统思考（system thinking）上

采用编码代理是必需的，因为这样做并不难，如果你不这样做，你就会被那些做的人取代。

好的 PM 很棒，差的 PM 很糟糕

优秀的产品思维（product thinking）比以往任何时候都更有价值——你可以构建有用的东西。糟糕的产品思维（product thinking）比以往任何时候都更浪费。如果某人有一个糟糕的产品想法，他们可以带着原型出现——但那个原型将是一个无用或构思不佳的功能。这些原型现在需要更多的评审——来自工程、产品和设计。这会浪费时间和资源。也存在更大的惯性将这些原型投入生产（“它已经存在了！我们合并它就行了！”）。这可能会导致创建出更糟糕或臃肿的产品。

系统思考是需要磨练的技能

在一个执行成本低廉的世界里，系统思考（system thinking）成为了区别。你应该专注于擅长系统思考（system thinking），并对你的特定领域（domain）有一个清晰的心智模型（mental model）：

工程：对如何架构服务（architect services）以及 API 和数据库（databases）有非常好的心智模型（mental model）
产品：对用户实际需要什么（而不是他们口头说想要什么）有非常好的心智模型（mental model）
设计：对为什么某些东西看起来和感觉用起来正确有非常好的心智模型（mental model）

系统思考（System thinking）一直很重要——那么改变了什么？实现的成本大大降低了。这意味着实现某些东西比以往任何时候都容易——但这并不意味着它很棒。成为一个优秀的系统思考者（system thinker）可以让你确保你从一开始（upfront）就构建正确的东西。它也让你可以在事后评审他人的工作。这两点都意味着成为一个优秀的系统思考者（system thinker）的重要性增加了。

每个人都需要产品感

编码代理（Coding agents）仍然需要有人提示（prompt）它们。有人告诉它们该做什么。如果你告诉它们构建错误的东西——你会给其他人带来更多的负担（slop）去评审。知道要告诉代理构建什么（“产品感”，product sense）是必需的，否则你将成为组织的累赘。这适用于工程、设计以及（显而易见的）产品部门。

EPD 的一个重要部分现在是评审原型。如果你有产品感（product sense），即使是评审设计/工程，评审也会更容易。如果你没有产品感（product sense），你需要在原型旁边附带一份超详细的产品文档。如果你有产品感（product sense），你就能以最少的规范（spec）理解功能的意图，从而加快沟通、评审和交付。

专业化的门槛更高了

你需要知道如何使用编码代理（coding agents）。你需要产品感（product sense）。所有角色都在融合。

角色之间一直存在重叠。设计和产品长期以来都是相互关联的——在某些公司，如苹果和爱彼迎，设计师担任产品经理。“设计工程师”（Design engineer）作为一个角色在 Vercel 等公司越来越受欢迎。

这并不意味着没有专业化的空间。一位只关注系统架构（system architecture）的资深工程师仍然很有价值。一位没有掌握气氛编码（vibe coding）但对客户问题和要构建什么有非常清晰的心智模型（mental model）的 PM 也是如此。同样，一位即使仍在 Figma 中也能理解和模拟用户旅程和交互的设计师也很有价值。

但专业化的门槛要高得多。你不仅必须在你的领域（domain）表现出色，还必须在评审方面非常迅速，并且是一位出色的沟通者。而且在任何一家公司，这种角色可能都不会太多。

你不是建造者就是评审者

我们看到 EPD 中出现了两种不同类型的角色。

第一种：建造者（builder）。这种原型（archetype）具有良好的产品思维（product thinking），能够使用编码代理（coding agents），并且具备基本的设计直觉（design intuition）。在他们的防护栏（guardrails）（测试套件，test suite；组件库，component library）的保护下，他们可以将小型功能从想法变为生产，并原型化（prototype）大型功能的可行版本。

第二种：评审者（reviewer）。对于大型复杂功能，需要详细的 EPD 评审。这方面的门槛很高——你必须是你的领域（domain）中出色的系统思考者（systems thinker）。你还必须以快速的节奏工作——有很多东西需要评审。

如果你现在是一名工程师——你应该要么致力于在系统设计（system design）方面变得出色，并习惯评审架构，并致力于成为一名评审者……要么尝试培养你的产品/设计技能，成为一名建造者。

如果你在产品或设计部门——你必须对产品/设计有出色的心智模型（mental model）并主要进行评审，或者投入编码代理（coding agents）并提高你的编码能力（coding chops）。

有趣的是，角色正在某种程度上崩溃，如上面图表所示，所有 EPD 成员都处于某个位置。角色可以开始融合——工程师有更多时间，可以更多地思考产品和设计。产品和设计可以创建代码。

每个人都认为他们的角色最受编码代理的优势——而且他们是对的

Twitter 上有一篇很棒的帖子（great post on Twitter），内容是关于最受编码代理（coding agents）优势的人：

那些对产品现状、其不足之处（soft）、其出彩之处（sings）以及如何迭代使其更锐利（sharper）有直观理解的人。

这种人中最稀有的一种处于文化与深度技术（deep technology）的交汇点。一个真正的双语者（bilingual）。他们知道什么是技术上可能的，也知道哪些文化潮流是真实（real）的，哪些是短暂（ephemeral）的。这种组合正是将那些感觉不可避免（inevitable）的产品与那些感觉拼凑而成（assembled）的产品区分开来的原因。

这篇帖子很好地概括了这个新世界，并且半病毒式传播（semi-viral）。它之所以能病毒式传播（viral）的一部分原因是，所有阅读它的人都认为它指的是他们自己或他们的角色。我看到产品经理、设计师、设计工程师（design engineers）、创始人（founders）……所有人都认为它适用于他们和他们的角色。

而且他们可能都说对了！我认为这个新世界最棒、最令人兴奋的地方在于，背景变得不那么重要了。我真诚地相信这种原型人物（archetype of person）可以来自产品、设计或工程部门。这并不意味着每个人都会成为这样的人——说起来容易做起来难。真正的独角兽（unicorns）少之又少。

这是一个令人兴奋的构建时代 :)

原文链接： x.com/hwchase17/status/2...

登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～

一张图看懂Web3稳定币格局

Fri, 20 Mar 2026 01:40:35 +0800

美国立法强制规定，国内私人稳定币与美元国债挂钩，换汤不换药，背书美元货币霸权。欧盟，新加坡在美国私人稳定币框架玩法内维护国家货币主权。中国应对： 1.2026年初全面叫停人民币稳定币。 2.开放港元稳定币参与试水积极参与。 3.发行数字人民币（央行背书国家信用）和美国私人化发行稳定币的框架对打，维护货币主权，定义Web3时代货币格局，包括央行数字货币桥等政策。总的来说，目前中国以吸收私人稳定币技术优势，如分布式账本，区块链技术等，助推数字人民币全球化竞争力，未开放私人稳定币应用。

nonReentrant 挡不住的重入：两种你可能忽略的场景

Fri, 20 Mar 2026 01:40:34 +0800

nonReentrant 挡不住的重入：两种你可能忽略的场景

作者：Mingyang Fan (@SymmaTe) 发布时间：2026-03

在审计智能合约的过程中，我发现一个很普遍的误区：很多开发者看到合约加了 nonReentrant，就认为重入问题已经解决了。但在实际的漏洞案例里，我见过两类"加了 nonReentrant 依然出问题"的场景，它们的根本原因不同，但都指向同一个结论：锁只能防止重入这个动作，防不了外部调用期间合约处于中间状态这个事实。

本文默认你已经了解经典重入攻击和 CEI 原则，直接进入这两种场景。

场景一：CEI 根本无法遵守——Balance Diff 模式

为什么 CEI 在这里失效

CEI 的核心是"先改完所有状态，再做外部调用"。但有一类合约的业务逻辑天生无法遵守这个原则——以 balance diff（余额差值） 来记账的合约：

记录调用前余额（balanceBefore）
↓
执行外部操作（swap、transfer 等）  ← 外部调用必须在这里
↓
记录调用后余额（balanceAfter）
↓
用差值作为实际转入/转出量

这个模式是处理 fee-on-transfer 代币的标准做法，外部调用必须夹在两次余额读取之间，无法前移。这意味着在外部调用发生期间，合约的最终状态永远是未确定的——这是结构决定的，加 nonReentrant 解决不了这个问题。

案例：Notional Finance redeemNative()

原始报告：Notional Finance · Sherlock audit https://solodit.cyfrin.io/issues/redeemnative-reentrancy-enables-permanent-fund-freeze-systemic-misaccounting-and-liquidation-cascades-mixbytes-none-notional-finance-markdown

攻击者构造了一条包含恶意 token 的 swap 路径（ETH → 恶意Token → WETH），在恶意 token 的回调里注入攻击逻辑。

没有 nonReentrant 时，经典的重入攻击：

攻击者调用 redeemNative()
    ↓
合约记录：balanceBefore = 1000 ETH
    ↓
合约执行 swap：ETH → 恶意Token → WETH
    ↓  ← 恶意Token的回调触发
    |
    └→ 【重入】攻击者再次调用 redeemNative()
           内层：balanceBefore = 1000 ETH（ETH 还没出去！）
           内层：执行 swap，ETH 转出 → balanceAfter = 900 ETH
           内层：diff = 100 ETH，给攻击者 100 份额
           ↓
    回到外层：balanceAfter = 900 ETH（ETH 已被内层取走）
    外层：diff = 100 ETH，再给攻击者 100 份额
    ↓
结果：攻击者用 100 ETH 的代价拿到了 200 份额的价值

为什么能成功？

关键在于 balanceBefore 是一个快照——它在函数最开始就拍下了"合约有 1000 ETH"。外层调用拍完快照之后，控制权通过回调交给了攻击者，攻击者的内层调用趁机把 ETH 取走了。等外层调用拿到 balanceAfter 时，ETH 已经少了，但外层的 balanceBefore 还是 1000，所以 diff 被算成了 100，实际上那 100 ETH 早就被内层拿走了。两层各自算了一遍 diff，100 ETH 被记了两次账。

加了 nonReentrant 之后：

内层再次调用 redeemNative() 被锁拒绝，上面这条路被堵住了。

但攻击者只需换一条路：在回调里不重入 redeemNative()，而是调用合约里其他没有被同一个锁保护的函数。

举例：假设合约里还有一个 claimRewards() 没有被同一个锁保护：

合约记录 balanceBefore = 1000 ETH
    ↓
合约执行 swap，恶意Token的回调触发
    ↓
    └→ 攻击者在回调里调用 claimRewards()
       claimRewards() 从合约取走 50 ETH 给攻击者
    ↓
回到 redeemNative()：
  balanceAfter = 850 ETH（100 ETH swap 花掉 + 50 ETH 被 claimRewards 取走）
  diff = 1000 - 850 = 150 ETH
  合约认为攻击者赎回了 150 份额的资产
  但攻击者实际只花了 100 ETH，额外拿走了 50 ETH

为什么 nonReentrant 没用？

nonReentrant 只是给 redeemNative() 这一个函数加了锁，但攻击者在回调里调用的是 claimRewards()——完全不同的函数，没有被同一把锁保护。锁拦截不了这条路。

根本问题没有改变：balanceBefore 和 balanceAfter 之间存在一个外部调用窗口，攻击者只要能控制这个窗口里发生的事，就能让 diff 的计算结果偏大。

真正的修复

不允许用户指定 swap 路径中的 token 地址，或对 token 合约做白名单限制——切断攻击者对外部调用行为的控制权。只要攻击者无法在回调里插入自己的代码，diff 的计算就是安全的。

场景二：遵守了 CEI 依然出问题——跨合约只读重入

场景一的根本原因是业务逻辑无法遵守 CEI。场景二更反直觉：代码遵守了 CEI，但依然有漏洞。

CEI 定义：先做 Effect（状态更新），再做 Interaction（外部调用）。

_burn = Effect（修改 totalSupply）
_transferAssets = Interaction（发送 ETH，触发外部回调）

先 burn 后 transfer，Effect 在前 Interaction 在后——这正是 CEI 要求的顺序。但它仍然产生了漏洞。

具体场景

// ️ 遵守了 CEI，但仍然危险
function redeem(uint256 shares, address receiver) external nonReentrant {
    _burn(msg.sender, shares);    // Effect：totalSupply↓，但 totalAssets 未变
    // ← 此刻 sharePrice = totalAssets / totalSupply 偏高
    _transferAssets(receiver);    // Interaction：发送 ETH，触发攻击者的 receive()
}

_burn 执行：totalSupply = 900，totalAssets = 1000
    ↓
sharePrice = 1000 / 900 = 1.11  ← 偏高（份额少了但资产还在）
    ↓
_transferAssets 发送 ETH，触发攻击者的 receive()
    ↓
攻击者的 receive() {
    // 此时 ETH 还没真正转出去，receive() 是在传输途中触发的
    // ERC4626 状态：totalSupply=900，totalAssets=1000，sharePrice=1.11
    lendingProtocol.borrow(ERC4626_share_as_collateral);
    // 借贷协议读到 sharePrice=1.11
    // 攻击者手里 100 shares，本来只值 100 USD
    // 现在被估值为 111 USD → 多借出 11 USD
}
    ↓
receive() 执行完，ETH 真正转出
totalAssets = 900，sharePrice 恢复正常
但攻击者已经用偏高的价格多借走了资产

为什么 nonReentrant 没用？

ERC4626 合约的 nonReentrant 保护的是 ERC4626 自身不被重入。但攻击者在 receive() 里调用的是借贷协议，完全是另一个合约——ERC4626 的锁管不到它。

借贷协议自己就算加了 nonReentrant 也没用，因为它的锁防的是借贷协议自身被重入，不影响它去读取 ERC4626 的状态数据。两个合约各自有各自的锁，没有任何一把锁能阻止这个跨合约的状态读取。

修复

调换顺序，先 transfer 后 burn：

//  安全顺序
function redeem(uint256 shares, address receiver) external nonReentrant {
    _transferAssets(receiver);    // 先发送 ETH，触发 receive()
    // ← receive() 触发时：totalSupply 和 totalAssets 都没有变化
    // ← sharePrice 完全正常，攻击者在回调里什么都做不了
    _burn(msg.sender, shares);    // receive() 执行完后再销毁 shares
    // ← burn 之后没有任何外部调用，无法被利用
}

为什么安全？

先执行 _transferAssets，ETH 开始发送，receive() 被触发。此时 _burn 还没有执行，所以 totalSupply 和 totalAssets 都没有任何变化，sharePrice 完全正常。攻击者在回调里读到的是正常价格，借贷协议不会给出超额授信。

等 receive() 执行完，ETH 才真正到账，然后 _burn 执行销毁份额。整个过程里，外部调用触发的那一刻状态是完整的，没有任何中间状态可以被利用。

两个场景的统一视角

表面上看两个场景很不一样，但背后的逻辑是一致的：

	场景一（balance diff）	场景二（只读重入）
CEI 的情况	无法遵守，业务逻辑决定的	遵守了 CEI，但依然有漏洞
外部调用来源	用户构造的恶意 swap 路径	ETH transfer 触发的 receive()
攻击者在回调里做什么	调用其他函数污染 balanceAfter	调用第三方合约读取偏高价格
nonReentrant 有没有用	没用，换条路就能绕过	没用，根本不需要重入
修复方向	限制外部调用的可控范围	调换顺序，让外部调用触发时状态完全正常

两者都利用了"外部调用期间合约处于中间状态"这个窗口。场景二更值得警惕——代码遵守了 CEI，看起来没有问题，但只要外部调用触发时有任何状态不一致，就可能被跨合约读取利用。

审计 Checklist

看到 balance diff 模式：

balanceBefore / balanceAfter 之间有外部调用吗？
外部调用的 token 地址或 swap 路径可以由用户指定吗？
合约里有没有其他没被同一个锁保护的函数可以被回调利用？

看到 ERC4626 或类似金库：

burn 和 transfer 的顺序是什么？先 burn 后 transfer = 危险
中间有外部调用（包括 ETH 转账触发的 receive）吗？
有没有第三方协议在读取这个合约的 sharePrice 或类似数据？

看到 nonReentrant 时不要放心，要问：

外部调用期间，合约的哪些状态是不一致的？
攻击者在回调里不重入任何函数，直接作恶，锁还有用吗？
有没有跨合约读取中间状态的可能？

重入攻击在 2016 年因为 The DAO 事件广为人知，但到今天仍然是审计中最容易被低估的一类漏洞。nonReentrant 是必要条件，但远不是充分条件。真正需要关注的不是"有没有加锁"，而是外部调用发生的那一刻，合约的状态是否完整一致。

零知识API使用信用：大型语言模型及其他应用

Fri, 20 Mar 2026 01:40:33 +0800

markdown

ZK API 使用积分：LLMs 及其他

Davide Crapis 和 Vitalik Buterin

这是 v2 版——与 v1 版相比，它将客户端的退款票据列表替换为服务器签名的同态退款运行总额，因此用户不再需要存储（或证明）不断增长的退款历史。

API 计量中的一个核心挑战是同时实现隐私、安全和效率。这对于使用 LLMs 进行 AI 推理尤其关键，因为用户会提交高度敏感的个人数据，但它也普遍适用于任何高频数字服务。目前，API 提供商被迫在两条次优路径中进行选择：

Web2 身份验证：需要身份验证（电子邮件/信用卡），这将每个请求与真实世界的身份关联起来，造成巨大的隐私泄露和画像风险。
链上支付：每个请求都需要一笔交易，这会极其缓慢、昂贵，并且难以模糊用户的完整交易图谱。

我们需要一个系统，用户可以一次性存入资金，然后匿名、安全、高效地进行数千次 API 调用。提供商必须获得付款保证并防止垃圾邮件，而用户则必须获得保证，其请求不会与其身份或彼此关联。我们将 LLM 推理作为主要的用例，但该方法是通用的，也适用于 RPC 调用或任何其他固定成本 API、图像生成、云计算服务、VPN、公共数据 API 等。

示例：

LLM 推理：用户将 $100$ USDC 存入智能合约，并对托管的 LLM 进行 $500$ 次查询。提供商收到 $500$ 个有效且已付费的请求，但无法将它们与同一存款人（或彼此）关联起来，同时用户的提示仍然无法与用户身份关联。
以太坊 RPC：用户存入 $10$ USDC，并向以太坊 RPC 节点（例如，eth_call / eth_getLogs）发出 $10,000$ 个请求，以支持钱包、索引器或机器人。RPC 提供商受到垃圾邮件防护并保证获得付款，但无法将请求关联成持久的用户档案。

提案概述： 我们利用 Rate-Limit Nullifiers (RLN) 将匿名性与经济权益绑定：遵守协议限制的诚实用户保持不可关联，而双重花费（或以其他方式超出其允许容量）的用户则会通过密码学方式披露其密钥，从而实现罚没。我们将协议设计为在 API 使用产生可变成本时也能工作，但它也直接支持更简单的固定成本每次调用作为特例。

我们采用一种灵活的记账协议，其中每个请求预先设置了每次调用的最大成本，一旦在调用结束时确定了实际成本，服务器就会发出退款。服务器会更新（并签名）一个同态加密的退款运行总额，用户可以在请求之间携带该总额。双重质押机制让服务器可以在执行合规策略的同时保持公开问责。

ZK API 使用积分协议

该协议利用服务器退款，并结合服务器签名的同态退款运行总额，用户可以在请求之间私下携带该总额。该模型通过要求用户证明其累计支出（由其当前的票据索引表示）严格在其初始存款和已验证的退款历史范围内来强制执行偿付能力。

反垃圾邮件保护是通过经济方式强制执行的：用户的吞吐量自然受到其可用存款缓冲的限制，同时任何尝试重复使用特定票据索引（双重花费）的行为都通过 Rate-Limit Nullifier 阻止。

原语

$k$：用户密钥。
$D$：初始存款。
$C_{max}$：每个请求的最大成本（预先扣除）。
$i$：票据索引（一个严格递增的计数器：$0, 1, 2, \dots$）。
$E(R)$：用户迄今收到的总退款的同态加密（例如，Pedersen commitment 或基于格的 HE）。
$\sigma_{srv}$：服务器对当前加密总额 $E(R)$ 发出的签名。

协议流程

用户生成密钥 $k$，推导出身份承诺 $ID = Hash(k)$，并将 $D$ 存入智能合约。合约将 $ID$ 插入链上 Merkle Tree。

重新随机化状态

用户选择一个新的随机致盲因子 $\eta'$ 并推导出一个新的匿名承诺：$E(R)_{anon} = E(R) \oplus E(0; \eta')$。

请求生成

用户选择下一个可用的票据索引 $i$。用户生成一个 ZK-STARK $\pi_{req}$ 来证明：

成员资格：$ID \in MerkleRoot$。
状态一致性：匿名 $E(R){anon}$ 是先前由服务器使用 $\sigma{srv}$ 签名的承诺 $E(R)$ 的有效重新随机化。
偿付能力（信用检查）： $$ (i + 1) \cdot C_{max} \le D + R $$ (在索引 $i$ 处的总潜在支出由存款加上所有已验证退款的总和覆盖。)
RLN Share 和 Nullifier：
- 斜率：$a = Hash(k, i)$
  - 注意： 与索引 $i$ 关联而不是与之前的哈希关联，以允许并行生成。
- Signal：$y = k + a \cdot Hash(M)$
- Nullifier：$Nullifier = Hash(a)$

提交

用户发送：Payload ($M$) + Nullifier + Signal ($x, y$) + Proof + 当前 $E(R)_{anon}$。

验证与罚没

服务器在其“已用票据”数据库中检查 Nullifier：

分叉/双重花费检查： 如果 Nullifier 存在但具有不同的 $x$（消息），则用户尝试在两个不同的请求上花费相同的票据。解出 $k$ 并罚没。
偿付能力检查： 验证 $\pi_{req}$ 以确保票据索引 $i$ 得到了用户当前资金水平的授权。

结算与退款更新

服务器执行请求并确定实际退款 $r = (C{max} - C{actual})$。
同态更新： 服务器将 $r$ 同态添加到当前加密中：$E(R^{new}) = E(R)_{anon} \oplus E(r)$。
签名： 服务器签署新的总额 $E(R^{new})$ 并将其（连同新签名 $\sigma^{new}$）发送回用户。

服务器端问责（双重质押）

为了阻止超出简单限速的 API 滥用（例如，违反服务条款、生成非法内容或越狱尝试），我们引入了一个辅助质押层。例如，用户可能会提交一个提示，要求模型生成制造武器的说明，或者帮助他们绕过安全控制——这些请求将违反许多提供商的使用政策，并且提供商可能希望阻止。

用户存入总金额 $Total = D + S$。

$D$ (RLN 质押)：受协议数学原理管辖。可以由任何提供双重信号数学证明（已揭示密钥 $k$）的人（包括服务器）认领。
$S$ (策略质押)：受服务器策略管辖。如果用户违反使用政策，服务器可以罚没（销毁），但不能认领。

这样做，而不是简单地提高 $D$，是为了消除服务器欺诈性地没收用户存款的动机，因为存款金额可能很高，具体取决于其大小。

S 的罚没机制

如果用户提交了一个违反策略的有效 RLN 请求（但没有触发数学上的双重花费陷阱）：

违规：服务器在请求 payload 中检测到策略违规（例如，禁止内容）。
销毁交易：服务器在智能合约上调用 slashPolicyStake() 函数。
- 输入：违规请求的 Nullifier 和 ViolationEvidence（可选哈希/原因）。
- 操作：合约从用户的存款中销毁金额 $S$。
- 约束：服务器不能为自己认领 $S$，它被发送到一个销毁地址。这可以防止服务器为了利润而虚假地封禁用户。
公开问责：罚没事件与相关的 Nullifier 一起记录在链上。虽然用户的身份仍然隐藏，但社区可以审计服务器销毁质押的频率以及这些销毁所发布的证据。

原文链接： hackmd.io/3da7PaYmTqmNTT...

登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～

Snap v2：以 BALs 取代 Trie 愈合 — 执行层研究

Fri, 20 Mar 2026 01:40:33 +0800

快照同步（snap/1）在 Geth v1.10.0 中发布后，极大地改善了以太坊节点的同步。但它有一个众所周知的阿喀琉斯之踵：trie 修复阶段，这是一个迭代过程，同步节点在此阶段一次一个 trie 节点地发现并修复状态不一致性。这个阶段导致节点在修复过程中停滞数天或数周，并被认为是社区希望消除的问题。

随着 EIP-7928（区块级访问列表）的引入，一种新方法成为可能：完全用顺序 BAL 应用取代 trie 修复。本文将解释快照同步目前的工作方式，trie 修复存在的问题，以及拟议的 snap/2 协议升级将如何解决这个问题。

第 1 部分：快照同步目前的工作方式

快照同步解决的问题

一个新的以太坊节点需要当前状态：每个账户余额、存储槽和合约字节码。这种状态存在于一个默克尔帕特里夏树中，其中账户 trie 的饱和深度约为 7 层（EF 博客：快照加速），包含数亿个节点。

旧的方法（“快速同步”，eth/63–66）从根开始逐个节点下载这个 trie。在约 11,177,000 区块时，状态包含 6.17 亿个 trie 节点，同步它们需要下载 43.8 GB 的数据，分布在 1,607M 个数据包中，总计约 10 小时 50 分钟的同步时间。

快照同步的关键洞察：完全跳过中间 trie 节点，将叶子（账户、存储）作为连续范围下载，然后在本地重建 trie。这要求服务节点维护一个动态快照，这是一个扁平的键值存储，可以在约 7 分钟内迭代账户，而原始 trie 迭代需要约 9.5 小时（参见 snap.md）。

比较快速同步与快照同步，我们得到了以下改进：

指标	快速同步	快照同步	改进
下载	43.8 GB	20.44 GB	-53%
上传	20.38 GB	0.15 GB	-99.3%
数据包	1,607M	0.099M	-99.99%
服务磁盘读取	15.68 TB	0.096 TB	-99.4%
时间	10 小时 50 分钟	2 小时 6 分钟	-80.6%

注意：这些基准测试来自约 11.2M 区块（2020 年末）。自那时起，状态有所增长，但相对改进仍然具有代表性。在良好硬件上，现代快照同步通常总共需要 2-3 小时。

三个阶段

快照同步分三个阶段进行：

\ sync690×260 28.6 KB

阶段 1 - 区块头下载

使用 eth 协议下载所有区块头，构建一个已验证的链。CL 驱动 EL，这意味着第一个 HEAD 从 CL 接收，然后 EL 从最新的区块头开始向后下载所有父区块头。

阶段 2 - 状态下载

节点选择一个枢轴区块 P（通常是 HEAD−64），并下载 P 处的完整状态：

GetAccountRange (0x00)：下载连续哈希范围内的账户，每个响应在边界处经过默克尔证明以防止间隙攻击
GetStorageRanges (0x02)：下载合约的存储槽，多个小合约可以批量处理到一个请求中
GetByteCodes (0x04)：下载合约代码，通过代码哈希比较进行验证

每个响应都以字节大小为上限（而不是数量），以实现可预测的带宽，并且不同的对等节点可以并发地服务不同的范围。服务节点为最近的 128 个区块（在每槽 12 秒的情况下，约 25.6 分钟）保留快照。

枢轴区块是链尖端足够远的过去区块，以确保我们不会下载因稍后重组的区块而产生的状态。64 个区块深度的重组实际上是不可能的。即使发生这样的重组，已下载的状态也无需丢弃，可以通过迭代获取所需的 trie 节点来修复。

关键在于，当每个状态范围被接收时，节点在本地重建并持久化该段的中间 trie 节点，而不是通过网络获取它们。到阶段 2 结束时，大部分 trie 已正确构建，显著减少了修复工作负载，只需修复因下载窗口期间发生的状态更改而变得不一致的节点。

阶段 3 - 修复

当阶段 2 运行时，链从 P 推进到 P+K，使下载的状态过时。修复解决了这个问题，但这也是问题开始的地方。

trie 修复的工作方式

修复阶段使用 GetTrieNodes (0x06) / TrieNodes (0x07) 迭代地发现并获取已更改的 trie 节点：

\ healing910×610 45.9 KB

为什么 trie 修复是瓶颈

迭代发现。 同步节点在查看之前不知道什么发生了变化。每一轮 GetTrieNodes 都会揭示下一组差异，需要另一次往返。这根本上是顺序的。
小负载，多次往返。 单个 trie 节点为 100–500 字节。即使是批量处理，每次往返的数据量相对于网络延迟来说也非常小。
移动的目标。 在 12 秒槽的情况下，每个区块大约删除 1,000 个 trie 节点并添加 2,000 个。修复必须超越这个速度，否则永远不会收敛。
随机磁盘访问。 服务 GetTrieNodes 需要随机数据库读取。与 GetAccountRange 使用的顺序读取相比，这成本高昂。
进度不可知。 正如 Geth 文档所指出：“无法监控状态修复的进度，因为在当前状态已经重新生成之前，错误的程度无法得知。”

实际影响可能很严重。例如，节点在修复过程中停滞了 2 周以上（4300 万个 trie 节点，下载了 11.7 GiB；吞吐量下降到约每秒 2 个 trie 节点），在修复期间停滞了 4 天或 6 天。

发布时的基准测试显示，在约 11.2M 区块时，修复增加了约 541,260 个 trie 节点（约 160 MiB），但随着今天更大的状态和更高的区块 gas 限制，修复负担已经大大加重，并将随着 gas 限制的进一步增加而恶化。

第 2 部分：区块级访问列表 (BAL)

EIP-7928 引入了区块级访问列表 (BAL)：记录区块执行期间访问的每个账户和存储位置以及执行后值的数据结构。每个区块头通过放置在区块头中的新 block_access_list_hash 字段提交其 BAL：

block_access_list_hash = keccak256(rlp.encode(block_access_list))

一个 BAL 包含每个访问过的账户：

存储更改：每个槽的执行后值，按导致更改的交易索引
存储读取：已读取但未修改的槽
余额/nonce/代码更改：交易后值

BAL 是 RLP 编码的，确定性排序的（账户按地址字典序排列，更改按交易索引），并且是完整的。状态差异是 BAL 的一个子集，因此可以在同步期间提供帮助。

BAL 大小

对在 60M 区块 gas 限制下 1,000 个主网区块的经验分析表明，BAL 平均大小约为 72.4 KiB。

节点必须至少保留 BAL 弱主观性周期（高达 3,533 个纪元，按当前验证者集大小计算约 15.7 天）。

第 3 部分：snap/2：基于 BAL 的状态修复

snap/2 没有迭代地发现和获取 trie 节点，而是颠倒了 snap/1 的模式。在 snap/1 中，trie 在下载期间增量构建，扁平状态从中导出。在 snap/2 中，只同步扁平状态（叶子），BAL 差异直接应用于其上，并且trie 从完整状态重建一次，从而消除了增量 trie 构建及其所需的复杂修复。

具体而言，节点不是迭代地发现和获取 trie 节点，而是下载同步期间前进的每个区块的 BAL，并顺序应用状态差异。区块集是预先知道的。每个 BAL 都根据其区块头承诺进行验证。这消除了迭代发现的需要。

snap/2 移除了 trie 修复消息，并用 BAL 取代它们，重用相同的消息 ID：

ID	snap/1	snap/2
0x00–0x05	账户/存储/字节码下载	不变
0x06	`GetTrieNodes`	`GetBlockAccessLists`
0x07	`TrieNodes`	`BlockAccessLists`

请注意，重用消息 ID 是安全的，因为 snap/2 是在 RLPx 握手期间协商的新协议版本。snap/1 对等节点永远不会看到 snap/2 消息。

新消息

GetBlockAccessLists (0x06)

[请求 ID: P, [区块哈希₁: B_32, 区块哈希₂: B_32, ...]]

BlockAccessLists (0x07)

[请求 ID: P, [区块访问列表₁, 区块访问列表₂, ...]]

节点必须始终响应
对于不可用的 BAL，使用空条目（零长度字节）
响应保留请求顺序，并且可以从尾部截断
建议的软限制为每个响应 2 MiB，这与现有消息（例如区块、区块头或收据）一致。

新同步算法

\ sync2910×380 28.2 KB

值得注意的是，由于 BAL 通过共识（BAL 哈希与规范区块的哈希检查）保证是正确的，因此状态根也保证匹配；因此，客户端甚至可以跳过最终的状态根比较步骤。

为什么这有效

使用 snap/2，修复窗口是有限且已知的。对于 HEAD−64 处的枢轴：

64 个区块 × 约 72.4 KiB（预计 60M gas）≈ 4.5 MiB 总 BAL 数据
在 2 MiB 软限制下，适合2–3 个响应
服务 BAL 只需几次磁盘查找，而不是为每个已更改的 trie 节点查找
总共 1–3 次往返（包括应用期间到达的任何“尾部”区块）
从 BAL 中提取状态差异纯粹是本地计算。无需 trie 遍历。

与 snap/1 相比，snap/2 的修复更高效，需要的磁盘读取和往返次数更少。理论上，有了 snap/2，链条就不可能超越同步了。

与 eth/71 的关系

EIP-8159 将 BAL 交换作为消息 0x12/0x13 添加到 eth 协议中。两者存在的原因不同：

	eth/71	snap/2
目的	用于并行执行、重组处理的最新 BAL	同步：修复期间批量 BAL 下载
数量	一次 1–3 个 BAL	一次多个 BAL
协议	所有节点必须使用	可选的卫星协议

eth/71 和 snap/2 中的消息重复是为了确保 snap 保持一个独立的卫星协议，并允许 snap 独立演进，例如，在未来版本中只提供状态差异而不是完整的 BAL，而无需更改 eth。

第 4 部分：比较

修复阶段：snap/1 vs snap/2

属性	snap/1 (trie 修复)	snap/2 (BAL 修复)
发现	迭代：节点在查看之前不知道什么发生了变化	确定性：P+1..P+K 区块是预先知道的
往返次数	数百次以上（问题报告数百万个 trie 节点）	最终数量待定，但估计只有几次
验证	复杂的 trie 重建 + 根比较	`keccak256(rlp(bal)) == header.block_access_list_hash`
移动的目标	每次修复轮次 + 链条前进 → 更多修复	BAL 应用是本地且快速的；尾部很小
收敛保证	弱：修复必须超越链条增长	强：确定性、有限的工作

比较 snap/1 与 snap/2 的完整流程如下：

\ snapv2flowdiagram1455×1995 294 KB

故障模式

故障	snap/1	snap/2
修复无法收敛	真实风险：trie 修复速度慢到链条可以超越它	几乎消除：只有 BAL 下载需要网络
不可用数据	无：snap/1 只要求修复超越链条	弱主观性周期（约 15.7 天）很宽裕
坏数据	默克尔证明捕获坏 trie 节点	哈希比较捕获坏 BAL
重组越过枢轴	可恢复：trie 修复根据新的规范链解决状态	如果保留了孤立的 BAL 则可恢复；否则需要同步重启

具体示例

考虑在区块 22,000,000 处的枢轴，当状态下载完成时，链条已领先 200 个区块：

snap/1： 从区块 22,000,200 的状态根开始 trie 遍历。每一轮发现更多差异，深入更深。同时，修复期间有多个新区块到达。在最佳情况下，这需要几分钟；在病态情况（慢磁盘、慢网络）下，它需要几天。

snap/2： 请求多个区块的 BAL。在 60M 区块 gas 限制下，这约为 4–5 MiB，适合几个响应。在本地应用 BAL，可选地验证状态根是否匹配。应用期间又到达了几个区块？获取 2–3 个更多 BAL。总计：2–3 次往返，几秒钟完成。

原文链接： ethresear.ch/t/snap-v2-r...

登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～

中本聪留给读者的习题

Fri, 20 Mar 2026 01:40:33 +0800

作者：Gloria Zhao

来源： https://learnblockchain.cn/article/24359

比特币白皮书对比特币的核心特性的说明非常清楚：它是免许可的。世界上的任何人，只要加入这个点对点网络并广播一笔交易，就能给另一个人支付（不管他是谁）。工作量证明共识机制甚至让任何人都能成为一个区块生产者，并且意味着：逆转一笔支付的唯一办法，就是控制超过其他所有人的算力。

但是，工作量证明只定义了如何在相互竞争的链条间挑出一个胜出者；它并不能帮助一个节点发现这样一条区块链。如果一个攻击者能够阻止目标节点们知道这些相互见证的链条，那么 “51% 攻击” —— 或者说 100% 攻击 —— 就容易多了。这个发现的工作，就落到了点对点模块上，它杂糅了许多自相矛盾的工作：在一个节点们总是来来去去的网络中，找出诚实的对等节点，但又不能依靠身份认证或者声誉机制；时刻留意区块和交易，但如果收到的大部分数据都是垃圾，也保持淡定；要强壮到能在最极端的敌意条件下生存，又要轻量到能够运行在树莓派（Raspberry Pi）单主板电脑上。

这个免许可的点对点网络的实现细节，在白皮书中毫无着墨，却成了今天的比特币节点软件的复杂性的大头。

过滤器与滥发

比特币白皮书承认公开交易的转发是比特币的抗审查性的基石，但是，关于它应该如何运行，就只有寥寥数语：“新交易会广播给所有节点。每个节点都会收集新交易、打包到一个区块中。每个节点都要持续运算，以为自己的区块找到一个工作量证明。” 1

许多人都觉得中本聪的这个想法很 “有趣”：每个节点都要挖矿。由于挖矿波动性的中心化压力，今天，网络中的绝大部分节点都不挖矿（寻找工作量证明）。也许，这是一个可以接受的结果（甚至是经济激励机制成功运行的结果），我们牺牲了一部分去中心化程度，换来了更多的哈希算力以及由此而来的安全性。然而，如果我们也放弃了交易转发的去中心化，比特币的抗审查性就会崩溃。

但是，我们对交易转发节点的宽阔暂存池的需求，必须根据计算机们每日暴露在免许可的网络中、处理来自匿名对等节点的数据的具体情形来取舍。这种威胁模型是独一无二的，并且需要非常谨慎的编程。

在区块下载方面，一个区块的工作量证明，已经优雅地充任了 “拒绝服务式攻击（DoS）” 的防范措施，以及一种衡量数据有用性的明确方法。相反，待确认的交易数据，是几乎可以免费创建的，而且可能是滥发的（spam）。比如说，我们不可能知道一笔交易是否满足了其输入的花费条件，除非我们加载（这些输入所指向的）UTXO，这可能需要从磁盘中读取出来。攻击者几乎毫无成本，就能触发这种相对高时延的活动：他们可以创建大体积的交易，使用不属于他们自己的输入，甚至是完全不存在的输入。

对交易的验证步骤，比如签名签名，以及交易依赖性的管理，可以消耗大量计算。很著名的一个例子是，带有大量传统的（隔离见证以前的）签名的一笔交易，在某些硬件上可能需要几分钟来验证 2，所以绝大部分节点都会过滤掉大体积的交易。这些资源的消耗不会仅仅局限在节点内部：被一个节点（的交易池）接纳的交易通常也会传播给其它对等节点，使用的带宽将与网络中的节点数量成正比。

节点保护自己的手段是限制未确认交易和验证队列的内存用量、为每个对等节点限制交易的处理速度，并且在共识规则之上实施交易池规则。虽然这些限制，如果没有仔细设计的话，可能会带来审查界面。诸如不下载此前已经拒绝过的交易、限制一个对等节点传输的交易队列的体积、在下载失败之后抛弃请求，这样的简单逻辑都有可能导致节点无法看见某一笔交易。这些 bug ，一旦被有心的攻击者利用，就会变成意料之外的审查界面。

由此可见，虽然不保留彼此重复花费的未确认交易是完全符合逻辑的（因为最终只有其中一笔交易会是有效的），但是，拒绝重复花费的交易，也就意味着早广播的那笔交易，就能阻止晚广播的那笔交易被挖出（得到区块确认）。而重复花费，也可能是伪造支付的有意之举；或者，当一个 UTXO（未花费的交易输出）属于多个人时，可能有人会利用节点的交易池策略来拖延或阻止其他人的二层协议结算交易被挖出，这被称为 “钉死攻击（pinning attack）”。那么，节点应该怎么做呢？

这个问题向我们揭示了交易转发的第二个元素：激励兼容性 3。虽然交易手续费在共识上，除了限制一个矿工能拿走多少区块奖励，别无其它意义，但它们在交易池队则中，作为一个衡量有用性的指标，扮演了重大角色。假设矿工们是由经济激励驱动的，节点就能估计哪些交易是最吸引矿工打包的、然后将最不吸引矿工的交易抛弃。如果多笔交易花费了同一个 UTXO，那么节点可以保留最吸引矿工的（打包起来最有利可图的）那一笔。虽然节点并不能收到交易手续费，它们可以将零手续费的交易当成滥发：它们会可能会使用网络资源，但永远不会被挖出，也就是几乎不花费任何成本就能创造出来。

这两个设计目标 —— DoS 抗性和激励兼容性 —— 也有矛盾之处。虽然允许用更高手续费的版本来替换已经出现的交易版本，对矿工有吸引力，但是，只需追加少量手续费就能重复替换交易，也可能会浪费网络的带宽。考虑待确认的交易之间的依赖性，可以带来挖矿收益更高的区块（并启用 “子为亲偿（CPFP）” 特性），但在复杂的交易间拓扑中，也可能会消耗大量资源。

（译者注：CPFP 指通过携带更高费率的子交易来提高打包父交易的吸引力，也即提高父交易的确认优先级。）

在历史上，节点依赖于启发式分析和依赖性限制，它们导致了用户体验摩擦，并且带来了新的钉死攻击界面。跟踪交易族群（cluster）的交易池实现可以更准确地估计激励兼容性，但依然必须限制交易池内的交易间依赖。这些类型的限制为涉及互不信任的多方的交易创造了钉死攻击界面：攻击者可以通过独自用尽配额来阻止参与共同交易的其他人使用 CPFP。

这些问题很容易被轻视：钉死攻击是一种小众的审查攻击类型，只能运用在多方共享的交易中，而且通常只会导致短暂的推迟确认。为了帮助不挖矿的节点节约几个聪的手续费，值得付出努力吗？

那么 Mevil 呢？

多方共享的交易，是基于 UTXO 混合的隐私解决方案以及二层协议的骨架。许多开发工作，都是致力于在二层协议上创建可扩展、隐私和特性丰富的应用；而这些协议会回到一层（也就是区块链内）来结算。一种常用的模式是暂时推迟取款（或者说结算），从而允许参与者们在一个时间窗口内应对其他人的不轨行为。但许多设计 —— 也包括那些用来鼓吹共识变更的设计 —— 都忽略了在这些场景中如何为交易追加手续费的问题。

防止不轨行为的时间窗口，也是攻击者的机会窗口。这两个条件 —— 多方共享交易和防止不轨行为的截止时间 —— 创造了完美的风暴，让钉死攻击能够从暂时推迟交易确认（嗯哼？）升级成潜在的盗窃（不是吧！）。

钉死攻击已经是多年的研究和开发的主题，从中产生除了 “拓扑受限直至确认（TRUC）” 交易格式 4，“支付到锚点（P2A）” 输出类型 5， “临时粉尘”交易池规则 6，“族群交易池” 实现 7，受限的交易包转发 8，以及许多对交易转发可靠性的提升。这些特性的设计目的是为传播共享交易的更高手续费替代版本提高更加强壮的保证。

但是，合理的手续费管理也有代价，比如更大体积的交易、更复杂的钱包软件逻辑、对不太可能发生的罕见情形的处理。想要轻松的捷径，也有，那就是跟一个矿工达成交易：你支付手续费，矿工保证你的交易会被优先打包。这种解决方案可能比使用点对点网络更加可靠 —— 后者可能会因为网络中的节点使用不同质的交易池策略，而有更高的时延和更慢的传播速度。

直接提交给矿工这种手法，可能会被迅速采用，毕竟有商业利益。交易所需要发送大量以，而且，比起优化手续费，可能更偏好可预测的确认时机。热门的应用可能会对钉死攻击不胜其烦，或者希望使用通行的交易池规则所禁止的非标准交易格式。担心量子短程攻击（quantum short-range attacks）的公司们和托管商们可能会跟一个矿工达成私下交易。

随着隐秘的 “矿工可抽取价值（MEVil）” 9 成为矿工保持竞争力的必要手段，比特币网络可能会走向中心化的区块空间经纪人模式。这些服务可能会成为攻击者和政府指令的目标，从而动摇 “无需许可即可成为矿工” 的承诺。

如果交易转发网络对于节点的运营变得无关紧要，那么可能参与其中也会显得毫无必要。在这种假想的未来，我们会不会像今天看待中本聪的想法（每个节点都是一个矿工）那样，认为 “每个节点都转发待确认的交易” 同样不可思议？

讽刺之处在于，挖矿中心化的压力并不起源于串通或监管压力。它竟来自一些理性的捷径：更高效的合约、定制化的转发路径，或者对参与者们有好处的性能优化。没有人能阻止这些合约出现。但我们可以尝试削弱这些私有服务对公开网络的竞争优势：在考虑可能提高 MEVil 潜力的共识变更以前，先驱逐交易池的钉死攻击界面；让公开的交易转发网络，成为竞标区块空间（以及更新竞标）的高效市场。

点对点网络是让比特币的许多核心意识形态获得生命的场所。它也是一个持续的工程挑战，要在节点高效运行、抗审查性、激励兼容性和协议复杂性之间作出艰难的取舍。随着比特币的状态，它只会变得更难。应该如何协调这些相互竞争的设计目标，是留给读者的习题。

（完）

参考文献

https://bitcoin.org/bitcoin.pdf ↩
https://delvingbitcoin.org/t/great-consensus-cleanup-revival/710 （中文译本） ↩
https://delvingbitcoin.org/t/mempool-incentive-compatibility/553 ↩
https://github.com/bitcoin/bips/blob/master/bip-0431.mediawiki ↩
https://github.com/bitcoin/bitcoin/pull/30352 ↩
https://bitcoinops.org/en/topics/ephemeral-anchors/ ↩
https://delvingbitcoin.org/t/an-overview-of-the-cluster-mempool-proposal/393?u=glozow （中文译本） ↩
https://bitcoinops.org/en/topics/package-relay/ ↩
https://bluematt.bitcoin.ninja/2024/04/16/stop-calling-it-mev/ （中文译本） ↩

本文转载自： btcstudy.org/2026/03/10/... , 如有侵权请联系管理员删除。

REVM源码阅读- Interpreter

Fri, 20 Mar 2026 01:40:32 +0800

Interpreter

REVM 是台计算机的话, Interpreter 就是 CPU .
由它来负责对字节码进行解释执行,完成本次交易想要实现的目的.
前面的内容最多算准备工作,提供 Interpreter 执行所需要的内容.
理解了它,才算真正入门了 REVM.

Interpreter 存在于每个 Frame 中,每次新建 Frame 会创建新的 Interpreter.
并不是整个交易共享一个 Interpreter.

先看下结构体定义中的类型,部分类型前面已经讲过,这里再概括下.
没讲的类型在下面展开讲.
把各个类型的功能和作用讲清楚,后面执行逻辑就是对各种类型的操作.

GasParams 这个类型,在 Frame 中已经讲过,保存 Opcode 静态和动态的 Gas 消耗.
Bytecode
Gas
Stack
ReturnData
Memory 共享内存Buffer, 每个 Frame 指定一个范围进行数据临时缓存.
Input
RuntimeFlag
Extend

// crates/interpreter/src/interpreter.rs
#[derive(Debug, Clone)]
#[cfg_attr(feature = "serde", derive(serde::Serialize, serde::Deserialize))]
pub struct Interpreter&lt;WIRE: InterpreterTypes = EthInterpreter> {
    /// Gas table for dynamic gas constants.
    pub gas_params: GasParams,
    /// Bytecode being executed.
    pub bytecode: WIRE::Bytecode,
    /// Gas tracking for execution costs.
    pub gas: Gas,
    /// EVM stack for computation.
    pub stack: WIRE::Stack,
    /// Buffer for return data from calls.
    pub return_data: WIRE::ReturnData,
    /// EVM memory for data storage.
    pub memory: WIRE::Memory,
    /// Input data for current execution context.
    pub input: WIRE::Input,
    /// Runtime flags controlling execution behavior.
    pub runtime_flag: WIRE::RuntimeFlag,
    /// Extended functionality and customizations.
    pub extend: WIRE::Extend,
}

ExtBytecode

上面的类型是 Bytecode, 但是使用的 ExtBytecode.
ExtBytecode 是在 ByteCode 的基础上再进行一层封装,分担了一部分 Interpreter 的工作.

Bytecode

先讲下 Bytecode 的部分
Bytecode 不是结构体,是枚举 Enum,分为两种:

Eip7702Bytecode EIP-7702类型,合约账户使用
- delegated_address 委托地址,就是我调用
- version 版本,现在只有一个版本0.
- raw 23字节的字节码.内容为 0xef01(固定) + 00(版本) + address(20字节的委托地址)
LegacyAnalyzedBytecode 传统字节码(现有的合约字节码)
- bytecode 字节码
- original_len 原始长度( bytecode 为了防止 pc 指向非法,会在尾部填充 STOP(0x00))
- jump_table JUMP 只能跳转到 JUMPDEST 指令,这里提前扫描保存了所有可跳转点.
  - jump_table 不是直接插入保存每个 JUMPDEST 的位置.
  - 是用一个长度等于 bytecode 的 bitvec<u8>,初始默认0,在 jumpdest 的位置标记为1,具体在后面解释.

// crates/bytecode/src/bytecode.rs
pub enum Bytecode {
    /// EIP-7702 delegated bytecode
    Eip7702(Arc&lt;Eip7702Bytecode>),
    /// The bytecode has been analyzed for valid jump destinations.
    LegacyAnalyzed(Arc&lt;LegacyAnalyzedBytecode>),
}
// crates/bytecode/src/eip7702.rs
pub struct Eip7702Bytecode {
    pub delegated_address: Address,
    pub version: u8,
    pub raw: Bytes,
}
// crates/bytecode/src/legacy/analyzed.rs
pub struct LegacyAnalyzedBytecode {
    bytecode: Bytes,
    original_len: usize,
    jump_table: JumpTable,
}

Eip7702Bytecode 的实现部分很简单.简单的 Getter.
new 和 new_raw 是在构造上面说的 raw 格式的内容.

impl Eip7702Bytecode {
    pub fn new_raw(raw: Bytes) -> Result&lt;Self, Eip7702DecodeError> {
        if raw.len() != 23 {
            return Err(Eip7702DecodeError::InvalidLength);
        }
        if !raw.starts_with(&EIP7702_MAGIC_BYTES) {
            return Err(Eip7702DecodeError::InvalidMagic);
        }

        // Only supported version is version 0.
        if raw[2] != EIP7702_VERSION {
            return Err(Eip7702DecodeError::UnsupportedVersion);
        }

        Ok(Self {
            delegated_address: Address::new(raw[3..].try_into().unwrap()),
            version: raw[2],
            raw,
        })
    }
    pub fn new(address: Address) -> Self {
        let mut raw = EIP7702_MAGIC_BYTES.to_vec();
        raw.push(EIP7702_VERSION);
        raw.extend(&address);
        Self {
            delegated_address: address,
            version: EIP7702_VERSION,
            raw: raw.into(),
        }
    }
    pub fn raw(&self) -> &Bytes {
        &self.raw
    }
    pub fn address(&self) -> Address {
        self.delegated_address
    }
    pub fn version(&self) -> u8 {
        self.version
    }
}

看下 LegacyAnalyzedBytecode 的实现.

只需要关注 analyze_legacy , 其他的都是 Getter.
跳到super::analysis::analyze_legacy 的具体实现
这个函数是为了获取前面的 jump_table , jump_table 是一个 bitvec<u8>.

看清楚这里是bitvec,而不是vec.这是一个坑,我一开始就搞错了.
它实际保存的是位图,不过用 u8 来实现.一个 u8 实际可以保存8个bool.
也就是这里jump_table中的操作都是位操作.一定要记住. pc 为 8 的jumpdest位置是在第2个字节,而不是第8个字节.
而且在字节中的顺序是逆序的,pc为8的话是第二个字节最右边的最低位,而不是最左边的最高位.

let range = bytecode.as_ptr_range(); 这里返回了 bytecode 的 起始指针 和 结束指针.
iterator 是指针位置.
while 循环并对 iterator 解引用获取所在位置的 Opcode.
- 判断 Opcode 是否 JUMPDEST, 是则将 jumps 中的该位置设置为 True.
  - set_unchecked 设置指定位置为 True.
  - iterator.offset_from_unsigned(start) ,计算 iterator - start 的值.
- 判断 Opcode 是否 PUSH1-PUSH32 (0x60 - 0x7f)
  - 如果是, iterator + push_offset + 2
在 bytecode 后面补充0x00 (STOP),避免后面执行代码时 PC 越界.
- let padding = (iterator as usize) - (end as usize) + (opcode != opcode::STOP) as usize
  - 这里是计算要补充几个 0x00.为什么不是只补充一个 0x00 我们讲下:
    - 正常没有 PUSH 指令, iterator 递增,不会有啥问题.
    - 如果最后一个 OP 是 PUSH32, bytecode 又被异常截断.导致数据不够,iterator跳转后会超出 end.
    - 这段代码就是处理这种异常情况,保证异常时也能执行.不够的数据填充0x00.

注: opcode.wrapping_sub(opcode::PUSH1) PUSH1-PUSH32是连续的 Opcode ,减去 PUSH1得到的值是在 0-31 ,说明就是 PUSH1-PUSH32.
PUSH 的指令比较特殊.它会将数据直接编码到指令后面. PUSHx 后面的 x个字节 都是它的数据.
所以 PUSH 指令的 iterator 是`iterator + (push_offset + 1) + 1

// crates/bytecode/src/legacy/analyzed.rs
impl LegacyAnalyzedBytecode {
    pub fn analyze(bytecode: Bytes) -> Self {
        let original_len = bytecode.len();
        let (jump_table, padded_bytecode) = super::analysis::analyze_legacy(bytecode);
        Self::new(padded_bytecode, original_len, jump_table)
    }
}

// crates/bytecode/src/legacy/analysis.rs
pub fn analyze_legacy(bytecode: Bytes) -> (JumpTable, Bytes) {
    if bytecode.is_empty() {
        return (JumpTable::default(), Bytes::from_static(&[opcode::STOP]));
    }

    let mut jumps: BitVec&lt;u8> = bitvec![u8, Lsb0; 0; bytecode.len()];
    let range = bytecode.as_ptr_range();
    let start = range.start;
    let mut iterator = start;
    let end = range.end;
    let mut opcode = 0;

    while iterator &lt; end {
        opcode = unsafe { *iterator };
        if opcode == opcode::JUMPDEST {
            // SAFETY: Jumps are max length of the code
            unsafe { jumps.set_unchecked(iterator.offset_from_unsigned(start), true) }
            iterator = unsafe { iterator.add(1) };
        } else {
            let push_offset = opcode.wrapping_sub(opcode::PUSH1);
            if push_offset &lt; 32 {
                // SAFETY: Iterator access range is checked in the while loop
                iterator = unsafe { iterator.add(push_offset as usize + 2) };
            } else {
                // SAFETY: Iterator access range is checked in the while loop
                iterator = unsafe { iterator.add(1) };
            }
        }
    }

    let padding = (iterator as usize) - (end as usize) + (opcode != opcode::STOP) as usize;
    let bytecode = if padding > 0 {
        let mut padded = Vec::with_capacity(bytecode.len() + padding);
        padded.extend_from_slice(&bytecode);
        padded.resize(padded.len() + padding, 0);
        Bytes::from(padded)
    } else {
        bytecode
    };

    (JumpTable::new(jumps), bytecode)
}

前面讲的是 Eip7702Bytecode 和 LegacyAnalyzedBytecode 的实现.
接下来继续讲下 Bytecode 的实现.
函数内容都一目了然,这里只给出函数列表和功能.

new() - 创建一个新的默认 Bytecode，包含一个 STOP 操作码的 legacy 分析字节码
legacy_jump_table() - 返回跳转表（如果是已分析的 legacy 字节码），否则返回 None
hash_slow() - 计算字节码的 Keccak-256 哈希值（如果为空则返回 KECCAK_EMPTY）
is_eip7702() - 判断字节码是否为 EIP-7702 类型
new_legacy(raw) - 从原始字节创建一个新的 legacy 字节码（会自动分析）
new_raw(bytecode) - 从原始字节创建字节码，自动检测类型（EIP-7702 或 legacy），格式错误时会 panic
new_raw_checked(bytes)- 从原始字节创建字节码，自动检测类型，格式错误时返回 Err
new_eip7702(address) - 从地址创建一个新的 EIP-7702 委托字节码
new_analyzed(bytecode, original_len, jump_table) - 直接创建已分析的 legacy 字节码（需提供跳转表）
bytecode() - 返回字节码的引用（&Bytes）
bytecode_ptr() - 返回可执行字节码的原始指针
bytes() - 返回字节码的克隆（Bytes）
bytes_ref() - 返回原始字节的引用（&Bytes）
bytes_slice() - 返回原始字节切片（&[u8]）
original_bytes() - 返回原始字节码（未填充的，克隆）
original_byte_slice() - 返回原始字节码切片（未填充的）
len() - 返回原始字节码的长度
is_empty() - 判断字节码是否为空
iter_opcodes() - 返回一个迭代器，遍历字节码中的操作码（跳过立即数）

ExtBytecode

照例先看下结构的部分:

instruction_pointer 指令指针位置.类似刚才讲的 analyze_legacy 中的 iterator
continue_execution 当前 Frame 是否结束.
bytecode_hash 当前 bytecode 的 keccak256 值.
action 返回结果,当前 Frame 是结束,还是创建 新的Frame
base 执行的字节码

// crates/interpreter/src/interpreter/ext_bytecode.rs
pub struct ExtBytecode {
    instruction_pointer: *const u8,
    continue_execution: bool,
    bytecode_hash: Option&lt;B256>,
    pub action: Option&lt;InterpreterAction>,
    base: Bytecode,
}

关键实现

pc 程序计数器,指示当前正在执行的字节码位置.
- 用instruction_pointer - 字节码起始位置 得到的值
opcode 当前执行的字节码
relative_jump 相对跳转,以当前 instruction_pointer 指向为基础进行 offset 的跳转.
absolute_jump 绝对条转,以字节码的起始位置进行 offset 的跳转.
is_valid_legacy_jump 是否合法跳转.通过查找跳转位置是否在 JumpTable 中.
read_u16 从 instruction_pointer 指向位置读取2个字节.
- EOF 格式专用,但 EOF 还没启用.
read_u8 从 instruction_pointer 指向位置读取1个字节.用于获取 Opcode
read_slice 从 instruction_pointer 指向位置读取指定长度字节. 用于 PUSH 类的 Opcode
read_offset_u16 从指定位置读取2个字节.EOF 格式专用, EOF 还没启用

// crates/interpreter/src/interpreter/ext_bytecode.rs
impl Jumps for ExtBytecode {
    fn relative_jump(&mut self, offset: isize) {
        self.instruction_pointer = unsafe { self.instruction_pointer.offset(offset) };
    }
    fn absolute_jump(&mut self, offset: usize) {
        self.instruction_pointer = unsafe { self.base.bytes_ref().as_ptr().add(offset) };
    }
    fn is_valid_legacy_jump(&mut self, offset: usize) -> bool {
        self.base
            .legacy_jump_table()
            .expect("Panic if not legacy")
            .is_valid(offset)
    }
    fn opcode(&self) -> u8 {
        // SAFETY: `instruction_pointer` always point to bytecode.
        unsafe { *self.instruction_pointer }
    }
    fn pc(&self) -> usize {
        unsafe {
            self.instruction_pointer
                .offset_from_unsigned(self.base.bytes_ref().as_ptr())
        }
    }
}
impl Immediates for ExtBytecode {
    fn read_u16(&self) -> u16 {
        unsafe { read_u16(self.instruction_pointer) }
    }
    fn read_u8(&self) -> u8 {
        unsafe { *self.instruction_pointer }
    }
    fn read_slice(&self, len: usize) -> &[u8] {
        unsafe { core::slice::from_raw_parts(self.instruction_pointer, len) }
    }
    fn read_offset_u16(&self, offset: isize) -> u16 {
        unsafe {
            read_u16(
                self.instruction_pointer
                    // Offset for max_index that is one byte
                    .offset(offset),
            )
        }
    }
}

Gas

用于记录当前 Frame 执行过程的 Gas 消耗和剩余记录.

看下结构体

limit 这里是当前 Frame 能用到的Gas Limit, 不是整个交易的
remaining 当前GasLimit 剩余
refunded 退款.(清零Storage之类的会退款)
memory 记录内存扩展花费.在 EVM 中内存扩展会花费,且成本不是线性,扩展越多花费越高.

实现都比较简单.只说下:

new(limit) 创建新的 Gas 实例，remaining 初始等于 limit
new_spent(limit) 创建已耗尽的 Gas 实例，remaining = 0
limit() 返回当前 frame 的 gas 上限
memory() 返回 MemoryGas 的不可变引用
memory_mut() 返回 MemoryGas 的可变引用
refunded() 返回累计的退款金额
spent() 返回已消耗的 gas (limit - remaining)
used() 返回实际使用的 gas (spent - refunded)
spent_sub_refunded() 同 used()，返回扣除退款后的消耗量
remaining() 返回剩余可用的 gas
erase_cost(returned) 把 gas 加回来，用于子调用返回时归还未用完的 gas
spend_all() 消耗所有剩余 gas，设置 remaining = 0
record_refund(refund) 记录退款值（可正可负）
set_final_refund(is_london) 设置最终退款，应用 EIP-3529 上限
set_refund(refund) 直接覆盖设置退款值
set_spent(spent) 直接设置已消耗的 gas 量
record_cost(cost) 扣除 gas，成功返回 true，不足返回 false
record_cost_unsafe(cost) 不安全版本的扣费，即使不足也执行减法，返回是否 OOG

// crates/interpreter/src/gas.rs
pub struct Gas {
    limit: u64,
    remaining: u64,
    refunded: i64,
    memory: MemoryGas,
}

看下内存 Memory 扩展的Gas消耗规则.

words_num word 数量,这里的 word 是32字节.64字节对应的就是2.
expansion_cost 当前累计的内存扩展成本
set_words_num 设置内存字数和扩展成本，返回新旧成本差值
record_new_len 记录新内存长度，返回额外 gas 成本或 None
- 关键公式:crate::gas::calc::memory_gas(new_num, linear_cost, quadratic_cost)
- 点进去查看 memory_gas 的具体实现:linear_cost.saturating_mul(num_words).saturating_add(num_words.saturating_mul(num_words) / quadratic_cost)
- 相当于 linear_cost × words + words² / quadratic_cost
- linear_cost 和 quadratic_cost 是固定值
- 实际并没有使用这个函数,具体的计算在 crates/interpreter/src/gas/params.rs中,但是公式还是一样的.

// crates/interpreter/src/gas.rs
pub struct MemoryGas {
    pub words_num: usize,
    pub expansion_cost: u64,
}

impl MemoryGas {
    #[inline]
    pub const fn new() -> Self {
        Self {
            words_num: 0,
            expansion_cost: 0,
        }
    }

    #[inline]
    pub fn set_words_num(&mut self, words_num: usize, mut expansion_cost: u64) -> Option&lt;u64> {
        self.words_num = words_num;
        core::mem::swap(&mut self.expansion_cost, &mut expansion_cost);
        self.expansion_cost.checked_sub(expansion_cost)
    }

    #[inline]
    pub fn record_new_len(
        &mut self,
        new_num: usize,
        linear_cost: u64,
        quadratic_cost: u64,
    ) -> Option&lt;u64> {
        if new_num &lt;= self.words_num {
            return None;
        }
        self.words_num = new_num;
        let mut cost = crate::gas::calc::memory_gas(new_num, linear_cost, quadratic_cost);
        core::mem::swap(&mut self.expansion_cost, &mut cost);
        Some(self.expansion_cost - cost)
    }
}

U256

数据在内存中的两个排序方式:
大端排序: 高位字节在低地址，低位字节在高地址
小端排序: 低位字节在低地址，高位字节在高地址
低地址在左边,高地址在右边

U256 不是在 REVM 源码里的, 属于 alloy 写的一个 Crate.
看下U256的类型.

// primitives-1.5.0/src/aliases.rs
macro_rules! int_aliases {
    ($($unsigned:ident, $signed:ident&lt;$BITS:literal, $LIMBS:literal>),* $(,)?) => {$(
        #[doc = concat!($BITS, "-bit [unsigned integer type][Uint], consisting of ", $LIMBS, ", 64-bit limbs.")]
        pub type $unsigned = Uint&lt;$BITS, $LIMBS>;

        #[doc = concat!($BITS, "-bit [signed integer type][Signed], consisting of ", $LIMBS, ", 64-bit limbs.")]
        pub type $signed = Signed&lt;$BITS, $LIMBS>;

        const _: () = assert!($LIMBS == ruint::nlimbs($BITS));
    )*};
}
int_aliases! {
    U8,   I8&lt;  8, 1>,
    ~~~
    U256, I256&lt;256, 4>,
    ~~~
    U512, I512&lt;512, 8>,
}

宏展开以后是下面这样的形式

Uint<256, 4> 中的 256 是位长. 4 是 limbs 数量.
1 个 limb 是 64位. 256 位也就是 4.如果有不足 64位 的,则按 1 算.
limbs = CEIL(BITS / 64).
U256 你可以理解成 4 个 U64 组成.

容易混淆的地方在这里.
U64 ,也就是一个 libm,它内部是大端排序的,高位数据在低位地址.
但他们组成 U256 的时候,这 4 个 limb 又是小端排序的,高位数据在高位地址.

例如数据 0x0102030405060708_0910111213141516_1718192021222324_2526272829303132
横线是为了方便理解

分成4个 U64,也就是
0x0102030405060708, 0x0910111213141516, 0x1718192021222324,0x2526272829303132.
分割后还是大端排序, 高位在低地址.

他们实际在栈中保存时候的顺序是
0x2526272829303132,0x1718192021222324,0x0910111213141516,0x0102030405060708
也即是小端排序,低位在低地址.

pub type U256 = Uint&lt;256, 4>;
const _: () = assert!(4 == ruint::nlimbs(256));  // 验证 limb 数量正确

这时候你再去看下面 push_slice_ 的代码.
先从左到右按 32 个字节分割出 U256 的类型.
再从右到到左分割 U64 类型并写入.

let words = slice.chunks_exact(32);
// 上面不足32个字节剩下的部分
let partial_last_word = words.remainder();

for word in words {
    // 这里是rchunks_exact,多了r,是从右向左.就是上面说的小端排序的原因
    // 这里i没有置零,原因就是栈是用vec模拟的,是连续的块内存.
    // 一直往后写入就行
    for l in word.rchunks_exact(8) {
        dst.add(i).write(u64::from_be_bytes(l.try_into().unwrap()));
        i += 1;
    }
}

Stack

栈的特性大家都理解了吧,先进后出.
EVM 是栈虚拟机,自然所有的计算、数据传递、控制流都要通过它来完成.

这里先不介绍具体虚拟机执行过程,介绍完基本类型之后再讲下这部分.
REVM 使用 Vec 对栈进行模拟,栈中所有的数据都是 256位(32字节)的.
REVM 栈中的数据是大端排序.数据的高位字节放在低位地址.低位字节放高位地址.
栈的最大深度为 1024.

pub struct Stack {
    data: Vec&lt;U256>,
}

大部分函数实现都很简单,只说下push_slice_.
传入的是 u8 数组类型,也就是一个字节数组.
一个栈的单元存储的是 32 自己的数据,所以插入时要计算要计算插入的格数.
具体逻辑直接在代码里注释解释方便点.

EVM中数据的存储是大端排序,高位字节在前（索引 0），低位字节在后（索引 31）.
但 REVM 中的 U256 是由4个 u64 构成的.这4个u64又是小端排序的,这里要注意.

// crates/interpreter/src/interpreter/stack.rs
fn push_slice_(&mut self, slice: &[u8]) -> bool {
    if slice.is_empty() {
        return true;
    }
    // 计算要插入的格数,
    let n_words = slice.len().div_ceil(32);
    // 计算插入后的长度,此时栈长度还是原来的
    let new_len = self.data.len() + n_words;
    if new_len > STACK_LIMIT {
        return false;
    }
    debug_assert!(self.data.capacity() >= new_len);
    unsafe {
        // self.data.as_mut_ptr() 数组0的位置, 加上栈长度就是指向栈顶.
        let dst = self.data.as_mut_ptr().add(self.data.len()).cast::&lt;u64>();
        self.data.set_len(new_len);
        let mut i = 0;
        // 从左向右,每32个字节,组成一个块.
        let words = slice.chunks_exact(32);
        // 上面不足32个字节剩下的部分
        let partial_last_word = words.remainder();

        for word in words {
            // 这里是rchunks_exact,多了r,是从右向左.就是上面说的小端排序的原因
            // 这里i没有置零,原因就是栈是用vec模拟的,是连续的块内存.
            // 一直往后写入就行
            for l in word.rchunks_exact(8) {
                dst.add(i).write(u64::from_be_bytes(l.try_into().unwrap()));
                i += 1;
            }
        }
        if partial_last_word.is_empty() {
            return true;
        }

        // 之前剩下不足32字节的,按8个字节进行分组.
        // 写入跟前面的方法一样.
        let limbs = partial_last_word.rchunks_exact(8);
        let partial_last_limb = limbs.remainder();
        for l in limbs {
            dst.add(i).write(u64::from_be_bytes(l.try_into().unwrap()));
            i += 1;
        }
        // 剩下不足8个字节的
        if !partial_last_limb.is_empty() {
            // 创建一个存有8个u8类型0的数组
            let mut tmp = [0u8; 8];
            // 把剩余字节右对齐复制到 tmp 高位（左边补 0）
            // 转成 u64 写入（高位补 0，保证大端序）。
            tmp[8 - partial_last_limb.len()..].copy_from_slice(partial_last_limb);
            dst.add(i).write(u64::from_be_bytes(tmp));
            i += 1;
        }
        debug_assert_eq!(i.div_ceil(4), n_words, "wrote too much");
        // 一个u256类型是4个u64,这里是如果最后一个word没写满,就补0
        let m = i % 4; // 32 / 8
        if m != 0 {
            dst.add(i).write_bytes(0, 4 - m);
        }
    }
    true
}

其他的函数功能:

len() 返回栈中当前元素数量
is_empty() 检查栈是否为空
data() 返回底层数据的不可变引用
data_mut() 返回底层数据的可变引用
into_data() 消耗栈并返回底层 Vec 数据
peek(n) 查看从栈顶往下第 n 个元素（不弹出）
pop() 弹出栈顶元素，栈空返回 StackUnderflow 错误
pop_unsafe() 无检查弹出栈顶（unsafe）
top_unsafe() 返回栈顶元素的可变引用（unsafe）
popn::<N>() 弹出栈顶 N 个元素并返回数组（unsafe）
popn_top::<POPN>() 弹出 POPN 个元素，同时返回新栈顶的可变引用（unsafe）
push(value) 压入一个 U256 值，栈满返回 false
push_slice(slice) 压入字节切片，按 32 字节分割，返回 Result
push_slice_(slice) 内部方法，压入字节切片，返回 bool
dup(n) 复制从栈顶往下第 n 个元素并压入栈顶（对应 DUP1~DUP16）
swap(n) 交换栈顶与第 n 个元素（对应 SWAP1~SWAP16）
exchange(n, m) 交换栈中位置 n 和位置 n+m 的元素（对应 EXCHANGE 指令）
set(n, val) 设置从栈顶往下第 n 个位置的值
clear() 清空栈中所有元素

ReturnData

上一次 CALL/RETURN 返回的数据缓冲区。供 RETURNDATACOPY / RETURNDATALOAD 使用。也用于当前帧的 RETURN 数据输出。

pub struct ReturnDataImpl(pub Bytes);
impl ReturnData for ReturnDataImpl {
    fn buffer(&self) -> &Bytes {
        &self.0
    }

    fn set_buffer(&mut self, bytes: Bytes) {
        self.0 = bytes;
    }
}

InputsImpl

当前调用帧的输入数据上下文.

target_address 目标地址.这里指的是实际修改状态的地址.例如合约A CALL 合约B,修改的是合约B的状态.如果是合约A DELEGATECALL 合约B,修改的是合约A的状态.
bytecode_address 字节码地址,也就是调用的合约地址.
caller_address 调用这次合约的地址.
input CallInput 类型,在 Frame 中详细介绍过了
call_value 本地调用发送的 Wei 数量.

pub struct InputsImpl {
    pub target_address: Address,
    pub bytecode_address: Option&lt;Address>,
    pub caller_address: Address,
    pub input: CallInput,
    pub call_value: U256,
}

impl InputsTr for InputsImpl {
    fn target_address(&self) -> Address {
        self.target_address
    }

    fn caller_address(&self) -> Address {
        self.caller_address
    }

    fn bytecode_address(&self) -> Option&lt;&Address> {
        self.bytecode_address.as_ref()
    }

    fn input(&self) -> &CallInput {
        &self.input
    }

    fn call_value(&self) -> U256 {
        self.call_value
    }
}

RuntimeFlags

is_static: 如果为 true，表示当前执行上下文处于只读模式.假设A合约通过 StaticCall 调用B合约, is_static 为 True ,调用过程中任何修改B合约状态的操作都会出错.
spec_id: EVM 硬分叉版本

// crates/interpreter/src/interpreter/runtime_flags.rs
pub struct RuntimeFlags {
    pub is_static: bool,
    pub spec_id: SpecId,
}

impl RuntimeFlag for RuntimeFlags {
    fn is_static(&self) -> bool {
        self.is_static
    }

    fn spec_id(&self) -> SpecId {
        self.spec_id
    }
}

Host

Host 封装了 Interpreter 执行过程中需要的所有函数.
大概看下这些的名字,会发现都很熟悉,又很混杂.
因为这个 Trait 是为了加一层封装,实际调用的是内部属性的方法.

在 REVM 中, 实现了 Host 这个 Trait 的是 Context.
实际调用的 Context 中 Block 、Transaction 、Config、Database、Journal、Log等中的方法.
大部分方法在之前都讲过了,这里直接略过

// crates/context/interface/src/host.rs
pub trait Host {
    fn basefee(&self) -> U256;
    fn blob_gasprice(&self) -> U256;
    fn gas_limit(&self) -> U256;
    fn difficulty(&self) -> U256;
    fn prevrandao(&self) -> Option&lt;U256>;
    fn block_number(&self) -> U256;
    fn timestamp(&self) -> U256;
    fn beneficiary(&self) -> Address;
    fn chain_id(&self) -> U256;
    fn effective_gas_price(&self) -> U256;
    fn caller(&self) -> Address;
    fn blob_hash(&self, number: usize) -> Option&lt;U256>;
    fn max_initcode_size(&self) -> usize;
    fn block_hash(&mut self, number: u64) -> Option&lt;B256>;
    fn selfdestruct(
        &mut self,
        address: Address,
        target: Address,
        skip_cold_load: bool,
    ) -> Result&lt;StateLoad&lt;SelfDestructResult>, LoadError>;
    fn log(&mut self, log: Log);
    fn sstore_skip_cold_load(
        &mut self,
        address: Address,
        key: StorageKey,
        value: StorageValue,
        skip_cold_load: bool,
    ) -> Result&lt;StateLoad&lt;SStoreResult>, LoadError>;
    fn sstore(
        &mut self,
        address: Address,
        key: StorageKey,
        value: StorageValue,
    ) -> Option&lt;StateLoad&lt;SStoreResult>> {
        self.sstore_skip_cold_load(address, key, value, false).ok()
    }
    fn sload_skip_cold_load(
        &mut self,
        address: Address,
        key: StorageKey,
        skip_cold_load: bool,
    ) -> Result&lt;StateLoad&lt;StorageValue>, LoadError>;
    fn sload(&mut self, address: Address, key: StorageKey) -> Option&lt;StateLoad&lt;StorageValue>> {
        self.sload_skip_cold_load(address, key, false).ok()
    }
    fn tstore(&mut self, address: Address, key: StorageKey, value: StorageValue);
    fn tload(&mut self, address: Address, key: StorageKey) -> StorageValue;
    fn load_account_info_skip_cold_load(
        &mut self,
        address: Address,
        load_code: bool,
        skip_cold_load: bool,
    ) -> Result&lt;AccountInfoLoad&lt;'_>, LoadError>;
    #[inline]
    fn balance(&mut self, address: Address) -> Option&lt;StateLoad&lt;U256>> {
        self.load_account_info_skip_cold_load(address, false, false)
            .ok()
            .map(|load| load.into_state_load(|i| i.balance))
    }
    #[inline]
    fn load_account_delegated(&mut self, address: Address) -> Option&lt;StateLoad&lt;AccountLoad>> {
        let account = self
            .load_account_info_skip_cold_load(address, true, false)
            .ok()?;

        let mut account_load = StateLoad::new(
            AccountLoad {
                is_delegate_account_cold: None,
                is_empty: account.is_empty,
            },
            account.is_cold,
        );
        if let Some(Bytecode::Eip7702(code)) = &account.code {
            let address = code.address();
            let delegate_account = self
                .load_account_info_skip_cold_load(address, true, false)
                .ok()?;
            account_load.data.is_delegate_account_cold = Some(delegate_account.is_cold);
            account_load.data.is_empty = delegate_account.is_empty;
        }

        Some(account_load)
    }
    #[inline]
    fn load_account_code(&mut self, address: Address) -> Option&lt;StateLoad&lt;Bytes>> {
        self.load_account_info_skip_cold_load(address, true, false)
            .ok()
            .map(|load| {
                load.into_state_load(|i| {
                    i.code
                        .as_ref()
                        .map(|b| b.original_bytes())
                        .unwrap_or_default()
                })
            })
    }
    #[inline]
    fn load_account_code_hash(&mut self, address: Address) -> Option&lt;StateLoad&lt;B256>> {
        self.load_account_info_skip_cold_load(address, false, false)
            .ok()
            .map(|load| {
                load.into_state_load(|i| {
                    if i.is_empty() {
                        B256::ZERO
                    } else {
                        i.code_hash
                    }
                })
            })
    }
}

// crates/context/src/context.rs
impl&lt;
        BLOCK: Block,
        TX: Transaction,
        CFG: Cfg,
        DB: Database,
        JOURNAL: JournalTr&lt;Database = DB>,
        CHAIN,
        LOCAL: LocalContextTr,
    > Host for Context&lt;BLOCK, TX, CFG, DB, JOURNAL, CHAIN, LOCAL>
{
    ...
}

InstructionTable

InstructionTable 是一个 Instruction 数组, 存储了 Opcode 的静态 Gas 和对应函数指针.
在 Interpreter 执行过程中,执行到指定 Opcode ,从 InstructionTable 找到指定的处理函数并运行.

先看 Instruction 结构体的定义.
就两个属性字段, fn_ 和 static_gas.
fn(InstructionContext<'_, H, W>) 就是接受一个 InstructionContext<'_, H, W> 类型参数的函数指针.
static_gas 就是当前 Opcode 的 静态Gas 消耗.

再看下 InstructionContext 结构体的定义.
两个属性字段, interpreter 和 host
interpreter 要求实现了 InterpreterTypes,就是当前我们讲的 Interpreter.
host 这里只要求实现了 ?Sized
如果是 Sized,表示类型在编译时大小是已知. ?Sized 则表示编译时大小未知,也就是动态大小,例如str(不是&str).
估计是为了支持其他链的不同需求,所以没有直接指明实现 Host Trait, REVM 中的抽象太多.

继续 Instruction 的实现.
impl<W: InterpreterTypes, H: Host + ?Sized> Instruction<W, H>,这里的 H 就要求必须要实现了 Host.
具体方法都比较简单,就不细讲了.

InstructionTable 的部分内容比较明了,但是长度长,这里略过.
返回的是一个 256 长度的数组. 数组的 Index 对应的 Opcode 保存的是对应的 Instruction

// crates/interpreter/src/instruction_context.rs
pub struct InstructionContext&lt;'a, H: ?Sized, ITy: InterpreterTypes> {
    /// Reference to the interpreter containing execution state (stack, memory, gas, etc).
    pub interpreter: &'a mut Interpreter&lt;ITy>,
    /// Reference to the host interface for accessing external blockchain state.
    pub host: &'a mut H,
}

// crates/interpreter/src/instructions.rs
pub struct Instruction&lt;W: InterpreterTypes, H: ?Sized> {
    fn_: fn(InstructionContext&lt;'_, H, W>),
    static_gas: u64,
}
impl&lt;W: InterpreterTypes, H: Host + ?Sized> Instruction&lt;W, H> {
    #[inline]
    pub const fn new(fn_: fn(InstructionContext&lt;'_, H, W>), static_gas: u64) -> Self {
        Self { fn_, static_gas }
    }
    #[inline]
    pub const fn unknown() -> Self {
        Self {
            fn_: control::unknown,
            static_gas: 0,
        }
    }
    #[inline(always)]
    pub fn execute(self, ctx: InstructionContext&lt;'_, H, W>) {
        (self.fn_)(ctx)
    }
    #[inline(always)]
    pub const fn static_gas(&self) -> u64 {
        self.static_gas
    }
}

pub type InstructionTable&lt;W, H> = [Instruction&lt;W, H>; 256];

#[inline]

pub const fn instruction_table&lt;WIRE: InterpreterTypes, H: Host>() -> [Instruction&lt;WIRE, H>; 256] {

const { instruction_table_impl::&lt;WIRE, H>() }

}

InstructionResult

InstructionResult 保存的是 Opcode 执行的返回结果.
这篇没有啥特别要讲的,只贴下 Enum 中各个类型的意义.

Stop 遇到了 STOP opcode（0x00），当前调用帧正常停止执行，不返回任何数据（默认值）
Return 执行到 RETURN opcode（0xf3），当前调用帧正常返回数据，将内存中指定范围的内容作为返回值返回给调用者
SelfDestruct 执行到 SELFDESTRUCT opcode（0xff），当前合约标记为自毁，余额转给指定受益者地址，合约代码将在交易结束时被删除
Revert 执行到 REVERT opcode（0xfd），当前调用帧回滚，将内存中指定范围的内容作为 revert reason 返回给调用者
CallTooDeep 调用深度超过 EVM 限制（通常 1024 层），无法继续执行 CALL / CREATE 等操作
OutOfFunds 转账或 CALL 时，发送者余额不足以支付 value + gas cost
CreateInitCodeStartingEF00 CREATE / CREATE2 的 initcode 以 0xEF00 开头（EIP-3541 规则），视为无效
InvalidEOFInitCode EOF 格式的 initcode 无效（格式错误、section 不完整等）
InvalidExtDelegateCallTarget ExtDelegateCall（EIP-7702 相关）调用的目标不是有效的 EOF 合约
OutOfGas gas 不足（通用 Out of Gas），执行过程中任何 gas 扣除超过剩余 gas 都会触发
MemoryOOG 内存扩展时 gas 不足（quadratic cost 导致）
MemoryLimitOOG 内存扩展超过了配置的内存上限（memory_limit）
PrecompileOOG precompile 执行时 gas 不足（precompile 有独立 gas 计算规则）
InvalidOperandOOG 操作数无效导致 gas 溢出或计算时 OOG
ReentrancySentryOOG 重入检查（reentrancy sentry）时 gas 不足
OpcodeNotFound 遇到了未知或未实现的 opcode（保留的或 fork 未激活的 opcode）
CallNotAllowedInsideStatic 在 static call（STATICCALL）中尝试执行修改状态的操作（如 SSTORE、CREATE、SELFDESTRUCT）
StateChangeDuringStaticCall static call 期间发生了状态变更（违反 static 规则）
InvalidFEOpcode 遇到了未定义的 opcode（0xfe，通常是 INVALID）
InvalidJump JUMP / JUMPI 的目标地址不是 JUMPDEST（0x5b），或越界
NotActivated 尝试使用当前 fork 未激活的功能或 opcode（如 EOF opcode 在 legacy fork 中）
StackUnderflow 栈下溢（POP、ADD 等操作时栈元素不足）
StackOverflow 栈上溢（PUSH 等操作时栈深度超过 1024）
OutOfOffset 内存/存储偏移量无效（负数或超大）
CreateCollision CREATE / CREATE2 时目标地址已存在（地址冲突）
OverflowPayment 支付金额溢出（value + gas_cost 超过 u256 最大值）
PrecompileError precompile 执行内部错误（输入非法、计算失败等）
NonceOverflow nonce 溢出（u64::MAX）
CreateContractSizeLimit 创建的合约代码大小超过限制（EIP-3860 等）
CreateContractStartingWithEF 创建的合约代码以 0xEF 开头（EIP-3541 规则，防止 EOF 冲突）
CreateInitCodeSizeLimit initcode 大小超过限制（EIP-3860）
FatalExternalError 外部数据库或其他宿主环境返回致命错误（db 读写失败等）

pub enum InstructionResult {
    #[default]
    Stop = 1, // Start at 1 so that `Result&lt;(), _>::Ok(())` is 0.
    Return,
    SelfDestruct,

    Revert = 0x10,
    CallTooDeep,
    OutOfFunds,
    CreateInitCodeStartingEF00,
    InvalidEOFInitCode,
    InvalidExtDelegateCallTarget,

    // Error Codes
    OutOfGas = 0x20,
    MemoryOOG,
    MemoryLimitOOG,
    PrecompileOOG,
    InvalidOperandOOG,
    ReentrancySentryOOG,
    OpcodeNotFound,
    CallNotAllowedInsideStatic,
    StateChangeDuringStaticCall,
    InvalidFEOpcode,
    InvalidJump,
    NotActivated,
    StackUnderflow,
    StackOverflow,
    OutOfOffset,
    CreateCollision,
    OverflowPayment,
    PrecompileError,
    NonceOverflow,
    CreateContractSizeLimit,
    CreateContractStartingWithEF,
    CreateInitCodeSizeLimit,
    FatalExternalError,
}

InterpreterAction

InterpreterAction 是当前 Frame 中的 Interpreter 执行指定Opcode后要求上层执行的动作.

NewFrame 是创建一个新的 Frame. Call 和 Create 相关的 Opcode 执行后的要求.
Return Interpreter 执行完成.
实现部分都比较简单,这里略过了.

FrameInput 在之前已经讲过了,不再复述.

#[derive(Clone, Debug, PartialEq, Eq)]
#[cfg_attr(feature = "serde", derive(serde::Serialize, serde::Deserialize))]
pub enum InterpreterAction {
    NewFrame(FrameInput),
    Return(InterpreterResult),
}
#[inline]
pub fn is_call(&self) -> bool {
    matches!(self, InterpreterAction::NewFrame(FrameInput::Call(..)))
}
#[inline]
pub fn is_create(&self) -> bool {
    matches!(self, InterpreterAction::NewFrame(FrameInput::Create(..)))
}
#[inline]
pub fn is_return(&self) -> bool {
    matches!(self, InterpreterAction::Return { .. })
}
#[inline]
pub fn gas_mut(&mut self) -> Option&lt;&mut Gas> {
    match self {
        InterpreterAction::Return(result) => Some(&mut result.gas),
        _ => None,
    }
}
#[inline]
pub fn into_result_return(self) -> Option&lt;InterpreterResult> {
    match self {
        InterpreterAction::Return(result) => Some(result),
        _ => None,
    }
}
#[inline]
pub fn instruction_result(&self) -> Option&lt;InstructionResult> {
    match self {
        InterpreterAction::Return(result) => Some(result.result),
        _ => None,
    }
}
#[inline]
pub fn new_frame(frame_input: FrameInput) -> Self {
    Self::NewFrame(frame_input)
}
#[inline]
pub fn new_halt(result: InstructionResult, gas: Gas) -> Self {
    Self::Return(InterpreterResult::new(result, Bytes::new(), gas))
}
#[inline]
pub fn new_return(result: InstructionResult, output: Bytes, gas: Gas) -> Self {
    Self::Return(InterpreterResult::new(result, output, gas))
}
#[inline]
pub fn new_stop() -> Self {
    Self::Return(InterpreterResult::new(
        InstructionResult::Stop,
        Bytes::new(),
        Gas::new(0),
    ))
}

看下 InterpreterResult 的部分

result 指令执行的返回结果,类型在前面讲过.
output 指令执行的返回数据.
- RETURN / REVERT 时：内存中返回或回滚的数据（revert reason 或 return value）。
  - CALL / CREATE 成功时：子调用返回的数据（如果有）。
- 其他情况下：通常为空 Bytes（空字节数组）
gas gas使用情况,类型在前面讲过.

// crates/interpreter/src/interpreter.rs
pub struct InterpreterResult {
    pub result: InstructionResult,
    pub output: Bytes,
    pub gas: Gas,
}

impl InterpreterResult {
    pub fn new(result: InstructionResult, output: Bytes, gas: Gas) -> Self {
        Self {
            result,
            output,
            gas,
        }
    }
    #[inline]
    pub const fn is_ok(&self) -> bool {
        self.result.is_ok()
    }
    #[inline]
    pub const fn is_revert(&self) -> bool {
        self.result.is_revert()
    }
    #[inline]
    pub const fn is_error(&self) -> bool {
        self.result.is_error()
    }
}

Outcome

Frame的返回值

result
memory_offset 返回数据在父调用帧内存中的写入范围
was_precompile_called 表示本次子调用是否执行了 precompile 合约
precompile_call_logs 如果子调用是 precompile 且产生了日志事件,这里保存这些日志。
address 新创建合约的地址（成功时为 Some(address)，失败时为 None）

// crates/interpreter/src/interpreter_action/call_outcome.rs
pub struct CallOutcome {
    pub result: InterpreterResult,
    pub memory_offset: Range&lt;usize>,
    pub was_precompile_called: bool,
    pub precompile_call_logs: Vec&lt;Log>,
}
// crates/interpreter/src/interpreter_action/create_outcome.rs
pub struct CreateOutcome {
    pub result: InterpreterResult,
    pub address: Option&lt;Address>,
}

REVM源码阅读- Interpreter(2)

Fri, 20 Mar 2026 01:40:32 +0800

前言

年前又爆仓,加上过年事情多.一直没有时间继续往下写.
过年回来调整了下状态,也为了爆仓后重新找份工作,接着写完这篇.

上一篇介绍了 Interpreter 的成员属性.这一篇写执行流程和Opcode.
为了配合这篇文章,写了个简单的网站来模拟 EVM 的执行过程.
这篇文章跟着模拟走,执行到哪就讲涉及到的Opcode.
网站:https://evm-ani.vercel.app/ 交易:https://etherscan.io/tx/0x005347d49f1fbcb3f0409dff3ef5e1c6f0186a2efb6be97a91facb0e8fdcbdd3
主合约:https://etherscan.io/address/0xa842927c9c9712394c57264716593db383c3a5cf#code
副合约:https://etherscan.io/address/0x0fb8f3bae4005f8ee539c20e6273b2aac25e5ad2#code

网站介绍

每次 Call 和 Create 都会创建一个 Frame.这里就是对应的 Frame.
1. 注: 为了方便理解才会每次都生成一个新的 Frame,实际可能调用的都是同一个地址的合约.
Opcode 列表,也就是调用的合约的字节码对应的Opcode列表.左边是 PC, 右边是具体OpCode.
Stack Interpreter 执行过程中的栈数据.
Memory Interpreter 执行过程中的内存数据.
Storage 合约的Storage数据,这里的数据我暂时没写.
ReturnData 每一次合约 Call 后的返回数据.
执行到哪一步时,Opcode 的作用解释.这里的 index 和 界面3的index 是相反的,这里的 index是从顶开始算
Context 对应的 Frame Id.calldata 是这次交易发送的数据.

执行过程

在 instruction_table_impl 中可以看到.
PUSH、DUP、SWAP、POP类的指令,直接调用stack的操作.
后续会直接跳过相关的操作.

// crates/interpreter/src/instructions.rs
const fn instruction_table_impl&lt;WIRE: InterpreterTypes, H: Host>() -> [Instruction&lt;WIRE, H>; 256] {
    use bytecode::opcode::*;
    let mut table = [Instruction::unknown(); 256];
    table[POP as usize] = Instruction::new(stack::pop, 2);

    table[PUSH0 as usize] = Instruction::new(stack::push0, 2);
    table[PUSH1 as usize] = Instruction::new(stack::push::&lt;1, _, _>, 3);

    table[DUP1 as usize] = Instruction::new(stack::dup::&lt;1, _, _>, 3);
    table[DUP2 as usize] = Instruction::new(stack::dup::&lt;2, _, _>, 3);

    table[SWAP1 as usize] = Instruction::new(stack::swap::&lt;1, _, _>, 3);
    table[SWAP2 as usize] = Instruction::new(stack::swap::&lt;2, _, _>, 3);
}

在网站中左上角,查看Opcodes的前3步.
分别是 PUSH1 0x80、PUSH1 0x40、MSTORE.
这三个 OpCode 合起来是在内存中 0x40 的位置写入0x80.
为什么这样做呢?这是因为 Solidity 的规定:

0x00 - 0x3f 这64个字节的位置为临时读写空间.主要勇于哈希计算.
0x40 - 0x5f 这32个字节为自由内存指针.告诉EVM,在这位置之后的空间你可以使用.
- 前面的三个Opcode对应的就是这里,指示 0x80 后面的空间都可以使用.
0x60-0x7f 零值空间,不被使用,永远为0.

当然,你在合约的 solidity 源码和 REVM 代码里都找不到关于这些的定义.
因为这部分写在编译器里了.
在将 solidity 源码编译成字节码的过程中,会自动进行内存指针的管理并写到字节码中.
REVM 只负责执行编译好的字节码.

常用宏

在讲其他 Opcode 前,先讲下几个宏

popn

功能很简单,就是从 interpreter 的栈中弹出 n 个元素.
#[macro_export] 指示当前宏可以在其他crate中使用.
([ $($x:ident),* ],$interpreter:expr $(,$ret:expr)? ) 这段不了解Rust宏的模式匹配看着是真头疼.
了解正则的话,可能会好点.一步一步拆分它

[ $($x:ident),* ]
- $x:ident, 相当于捕获一个 ident(变量名、函数名) 类型的语法片段,命名为 $x.
- [ $($x:ident),* ] 这里的 * 是重复捕获.匹配零次或者多次.
$interpreter:expr 捕获一个 expr(表达式) 类型的语法片段.
$(,$ret:expr)? 可选捕获,也就是0 或者 1个.
let Some([$( $x ),*]) 前面匹配到的 $x 会传入到数组中.
$interpreter.stack.popn() 会根据匹配到的数组数量弹出相同的数量.如果数量不足,则返回halt_underflow.

popn!([offset, value], context.interpreter) 大部分 popn 宏的使用形式.从context.interpreter 弹出两个元素,赋值到 offset、value.

// crates/interpreter/src/instructions/macros.rs
#[macro_export]
#[collapse_debuginfo(yes)]
macro_rules! popn {
    ([ $($x:ident),* ],$interpreter:expr $(,$ret:expr)? ) => {
        let Some([$( $x ),*]) = $interpreter.stack.popn() else {
            $interpreter.halt_underflow();
            return $($ret)?;
        };
    };
}
// crates/interpreter/src/interpreter/stack.rs
#[inline]
fn popn&lt;const N: usize>(&mut self) -> Option&lt;[U256; N]> {
    if self.len() &lt; N {
        return None;
    }
    // SAFETY: Stack length is checked above.
    Some(unsafe { self.popn::&lt;N>() })
}

popn_top

也是从 stack 弹出 n 个元素.不同的是这里会返回栈顶的指针.
不深入讲解了.和上面的逻辑差不多.

#[macro_export]
#[collapse_debuginfo(yes)]
macro_rules! popn_top {
    ([ $($x:ident),* ], $top:ident, $interpreter:expr $(,$ret:expr)? ) => {
        /*
        let Some(([$( $x ),*], $top)) = $interpreter.stack.popn_top() else {
            $interpreter.halt($crate::InstructionResult::StackUnderflow);
            return $($ret)?;
        };
        */

        // Workaround for https://github.com/rust-lang/rust/issues/144329.
        if $interpreter.stack.len() &lt; (1 + $crate::_count!($($x)*)) {
            $interpreter.halt_underflow();
            return $($ret)?;
        }
        let ([$( $x ),*], $top) = unsafe { $interpreter.stack.popn_top().unwrap_unchecked() };
    };
}

resize_memory

如果有需要的话会调整内存的大小.
$crate 指的是当前宏所在的 crate.
如果传入的是 3 个参数,加一个()再调用一遍宏.
如果是 4 个参数则调用 interpreter 下的 resize_memory.
let new_num_words = num_words(offset.saturating_add(len)); 这里是用(offset + len)/32 并向上取整来计算需要的 words.

例如我在 0x65(101) 写入 32 个字节. new_num_words = (101 + 32)/32 = 5.

gas 消耗的计算公式在前面说过了$$Cost = (size^2 / 512) + (3 \times size)$$
memory.resize(new_num_words * 32) 来实际调整大小.

// crates/interpreter/src/instructions/macros.rs
macro_rules! resize_memory {
    ($interpreter:expr, $offset:expr, $len:expr) => {
        $crate::resize_memory!($interpreter, $offset, $len, ())
    };
    ($interpreter:expr, $offset:expr, $len:expr, $ret:expr) => {
        if let Err(result) = $crate::interpreter::resize_memory(
            &mut $interpreter.gas,
            &mut $interpreter.memory,
            &$interpreter.gas_params,
            $offset,
            $len,
        ) {
            $interpreter.halt(result);
            return $ret;
        }
    };
}
//crates/interpreter/src/interpreter.rs
pub fn resize_memory(&mut self, offset: usize, len: usize) -> bool {
    if let Err(result) = resize_memory(
        &mut self.gas,
        &mut self.memory,
        &self.gas_params,
        offset,
        len,
    ) {
        self.halt(result);
        return false;
    }
    true
}
// crates/interpreter/src/interpreter/shared_memory.rs
pub fn resize_memory&lt;Memory: MemoryTr>(
    gas: &mut crate::Gas,
    memory: &mut Memory,
    gas_table: &GasParams,
    offset: usize,
    len: usize,
) -> Result&lt;(), InstructionResult> {
    #[cfg(feature = "memory_limit")]
    if memory.limit_reached(offset, len) {
        return Err(InstructionResult::MemoryLimitOOG);
    }

    let new_num_words = num_words(offset.saturating_add(len));
    if new_num_words > gas.memory().words_num {
        return resize_memory_cold(gas, memory, gas_table, new_num_words);
    }

    Ok(())
}
fn resize_memory_cold&lt;Memory: MemoryTr>(
    gas: &mut crate::Gas,
    memory: &mut Memory,
    gas_table: &GasParams,
    new_num_words: usize,
) -> Result&lt;(), InstructionResult> {
    let cost = gas_table.memory_cost(new_num_words);
    let cost = unsafe {
        gas.memory_mut()
            .set_words_num(new_num_words, cost)
            .unwrap_unchecked()
    };

    if !gas.record_cost(cost) {
        return Err(InstructionResult::MemoryOOG);
    }
    memory.resize(new_num_words * 32);
    Ok(())
}

gas

判断 Gas 是否足够支付,并记录Gas消耗.

// crates/interpreter/src/instructions/macros.rs
#[macro_export]
#[collapse_debuginfo(yes)]
macro_rules! gas {
    ($interpreter:expr, $gas:expr) => {
        $crate::gas!($interpreter, $gas, ())
    };
    ($interpreter:expr, $gas:expr, $ret:expr) => {
        if !$interpreter.gas.record_cost($gas) {
            $interpreter.halt_oog();
            return $ret;
        }
    };
}
// crates/interpreter/src/gas.rs
pub fn record_cost(&mut self, cost: u64) -> bool {
        if let Some(new_remaining) = self.remaining.checked_sub(cost) {
            self.remaining = new_remaining;
            return true;
        }
        false
    }

MSTORE

看下代码逻辑:
popn!([offset, value], context.interpreter) 从 Stack 中弹出两个元素.
栈顶是 offset,接着是 value.
as_usize_or_fail! 用于将 U256 类型转换成 usize.这里不进行内部解释了.
resize_memory!(context.interpreter, offset, 32); 检测是否需要调整内存大小.
context.interpreter.memory.set(offset, &value.to_be_bytes::<32>()); 在 offset 中填入 value.
在网站中跳到第4步(第三步执行完成).可以看到内存中出现了数据,最后一位为 80.

这篇文章是为了跟随网站的模拟过程,所以暂时不讨论其他的内存相关的Opcode.
感兴趣的自己可以先看下,跟这个逻辑类似.

// crates/interpreter/src/instructions/memory.rs
pub fn mstore&lt;WIRE: InterpreterTypes, H: ?Sized>(context: InstructionContext&lt;'_, H, WIRE>) {
    popn!([offset, value], context.interpreter);
    let offset = as_usize_or_fail!(context.interpreter, offset);
    resize_memory!(context.interpreter, offset, 32);
    context
        .interpreter
        .memory
        .set(offset, &value.to_be_bytes::&lt;32>());
}

MLOAD

从内存中加载数据.

逻辑比较简单,就不解释了.

pub fn mload&lt;WIRE: InterpreterTypes, H: ?Sized>(context: InstructionContext&lt;'_, H, WIRE>) {
    popn_top!([], top, context.interpreter);
    let offset = as_usize_or_fail!(context.interpreter, top);
    resize_memory!(context.interpreter, offset, 32);
    *top =
        U256::try_from_be_slice(context.interpreter.memory.slice_len(offset, 32).as_ref()).unwrap()
}

CALLDATASIZE

清晰明了,计算出 input 的 len 并 push 到 stack 中.
执行到 第8步 ,栈中插入 0x24.
因为 calldata 是0x769c02d50000000000000000000000000000000000000000000000000000000000000001.
36个字节,前面是函数的abi encode,后面是函数参数.转成16进制就是0x24.

pub fn calldatasize&lt;WIRE: InterpreterTypes, H: ?Sized>(context: InstructionContext&lt;'_, H, WIRE>) {
    push!(
        context.interpreter,
        U256::from(context.interpreter.input.input().len())
    );
}

LT

比较栈顶两个元素的大小.
为了方便理解,后面栈顶用 index 为 1 表示,次栈顶用 index 为 2 表示,以此类推.
popn_top 弹出两个元素并返回栈顶的指针.
假设栈顶为a,次栈顶为b, if a < b, then 1, else 0.
并将比较结果插入栈顶.
执行第6,7步,栈中元素从上到下是 0x24 , 0x4, 0x24 > 0x4, 所以结果是0.

// crates/interpreter/src/instructions/bitwise.rs
pub fn lt&lt;WIRE: InterpreterTypes, H: ?Sized>(context: InstructionContext&lt;'_, H, WIRE>) {
    popn_top!([op1], op2, context.interpreter);
    *op2 = U256::from(op1 &lt; *op2);
}

JUMPI

条件跳转Op.
栈顶为跳转目的地,次栈顶为跳转条件.
如果次栈顶为1,则跳转到目的地.如果为 0,则PC + 1

jump_table 我在上一章中可能写错,改了但是不确定有没有改完.
jump_table 是用 u8 实现的位图. 是 bitvec<u8>. jumpdest 的 pc 对应的第几位(bit),而不是第几个byte.

is_valid_legacy_jump 最终调用 JUMPTABLE中的 is_valid.
table_ptr: jump_table 指针. pc >> 3, 右移3位, 相当于除以8. 因为一个字节就是 8 位.这里是找出位于第几个字节. 1 << (pc & 7),pc & 7这里的功能相当于% 8, 找出字节中第几位是 dest.结果是0-7. 1 <<` 是因为上一章我们说过JumpTable的排序在字节之间是顺序的,在字节内部是逆序的.也就是从低位到高位,而不是符合阅读习惯的从高到低.这个操作同时保证了一个字节中只有一位是1.

在网站中,这次跳转条件不满足,PC + 1往下运行.

// crates/interpreter/src/instructions/control.rs
pub fn jumpi&lt;WIRE: InterpreterTypes, H: ?Sized>(context: InstructionContext&lt;'_, H, WIRE>) {
    popn!([target, cond], context.interpreter);
    if !cond.is_zero() {
        jump_inner(context.interpreter, target);
    }
}
fn jump_inner&lt;WIRE: InterpreterTypes>(interpreter: &mut Interpreter&lt;WIRE>, target: U256) {
    let target = as_usize_or_fail!(interpreter, target, InstructionResult::InvalidJump);
    if !interpreter.bytecode.is_valid_legacy_jump(target) {
        interpreter.halt(InstructionResult::InvalidJump);
        return;
    }
    // SAFETY: `is_valid_jump` ensures that `dest` is in bounds.
    interpreter.bytecode.absolute_jump(target);
}
//crates/bytecode/src/legacy/jump_map.rs
pub fn is_valid(&self, pc: usize) -> bool {
        pc &lt; self.len && unsafe { *self.table_ptr.add(pc >> 3) & (1 &lt;&lt; (pc & 7)) != 0 }
    }

CALLDATALOAD

offset_ptr 保存的是栈顶指针.
let offset = as_usize_saturated!(offset_ptr) 这里传入的是指针,但会自动解引用获取栈顶的元素,并转成 usize. offset 保存的是要读取 calldata 的偏移位置.
let count = 32.min(input_len - offset); 默认读取32字节,如果剩余不足则读取剩余的.
判断 input 类型

Bytes 类型,直接复制 count 字节的数据到 word 中.
SharedBuffer 类型,从内存中读取数据后再复制到word中.
*offset_ptr = word.into() 将 word 的数据写入到栈顶.
网站中运行到11步,可以看到栈中数据为:
0x769c02d500000000000000000000000000000000000000000000000000000000.

// crates/interpreter/src/instructions/system.rs
pub fn calldataload&lt;WIRE: InterpreterTypes, H: ?Sized>(context: InstructionContext&lt;'_, H, WIRE>) {
    popn_top!([], offset_ptr, context.interpreter);
    let mut word = B256::ZERO;
    let offset = as_usize_saturated!(offset_ptr);
    let input = context.interpreter.input.input();
    let input_len = input.len();
    if offset &lt; input_len {
        let count = 32.min(input_len - offset);

        match context.interpreter.input.input() {
            CallInput::Bytes(bytes) => {
                unsafe {
                    ptr::copy_nonoverlapping(bytes.as_ptr().add(offset), word.as_mut_ptr(), count)
                };
            }
            CallInput::SharedBuffer(range) => {
                let input_slice = context.interpreter.memory.global_slice(range.clone());
                unsafe {
                    ptr::copy_nonoverlapping(
                        input_slice.as_ptr().add(offset),
                        word.as_mut_ptr(),
                        count,
                    )
                };
            }
        }
    }
    *offset_ptr = word.into();
}

SHR

右移操作.将数据向右移动 n 位.移出的低位将被丢弃.高位部分补0.
这里是按位进行计算,不是按字节.

check!(context.interpreter, CONSTANTINOPLE) check宏检测指定硬分叉版本是否启用.
popn_top!([op1], op2, context.interpreter) 弹出栈顶到 op1 , 保存的是要移动的位数.
op2 保存的是弹出移动位数后的栈顶指针.
判断要移动的位数是否小于 256.是则右移指定位数并保存回栈顶.

网站执行11步将 0xe0 写入栈顶.执行12步进行右移操作.
0x769c02d500000000000000000000000000000000000000000000000000000000 右移 0xe0(224位,28个字节).结果是 0x769c02d5.再将 0x769c02d5 写入栈顶.

// crates/interpreter/src/instructions/bitwise.rs
pub fn shr&lt;WIRE: InterpreterTypes, H: ?Sized>(context: InstructionContext&lt;'_, H, WIRE>) {
    check!(context.interpreter, CONSTANTINOPLE);
    popn_top!([op1], op2, context.interpreter);
    let shift = as_usize_saturated!(op1);
    *op2 = if shift &lt; 256 {
        *op2 >> shift
    } else {
        U256::ZERO
    }
}

一直执行到17步,前面那几步是为了找到 0x769c02d5(runFullOpcodeSuite) 函数对应的PC位置.
这里开始进行跳转.
跳转后指定函数后,还会进行一系列的检查和加载数据.
加载函数的参数、检测payable等等.我们的任务不是学习反编译.所以这部分都跳过.
直接跳到 104 步,这里是函数主体开始的地方.

ADDRESS

将 target_address 地址入栈.
如果你去看网站对应的 solidity 源码,你要搞清楚.
这里 ADDRESS 出现是因为 this,而不是因为address(this) 中的 address.
solidity 中 address 只是类型转换. this 是获取 target_address.

// crates/interpreter/src/instructions/system.rs
pub fn address&lt;WIRE: InterpreterTypes, H: ?Sized>(context: InstructionContext&lt;'_, H, WIRE>) {
    push!(
        context.interpreter,
        context
            .interpreter
            .input
            .target_address()
            .into_word()
            .into()
    );
}

CALLVALUE

将 Transaction 发送时带的 Value 压入栈.

网站发送的交易我发送了 0.00001 ETH(10000000000000 WEI, 0x9184e72a000).
执行108步,将 0x9184e72a000 压入栈.

// crates/interpreter/src/instructions/system.rs
pub fn callvalue&lt;WIRE: InterpreterTypes, H: ?Sized>(context: InstructionContext&lt;'_, H, WIRE>) {
    push!(context.interpreter, context.interpreter.input.call_value());
}

GASPRICE

将 Transacton 发送时带的 GasPrice 压入栈.

真实交易的 GasPrice 是2032443413 Wei
网站上112步模拟的交易入栈的是 0x79aadd5e(2041240926)
是因为模拟的时候可能 Block 的 Basefee 和 Tx 的 PriorityFee 会有不同.

// crates/interpreter/src/instructions/tx_info.rs
pub fn gasprice&lt;WIRE: InterpreterTypes, H: Host + ?Sized>(
    context: InstructionContext&lt;'_, H, WIRE>,
) {
    push!(context.interpreter, context.host.effective_gas_price());
}

ADDMOD

将两个数相加并对另一个数取模

源码中是将 msg.value 和函数参数进行相加,并对 100 就行取模.
网站中拖到 125 步. 此时栈顶自上而下是

0x0000000000000000000000000000000000000000000000000000000000000001(1)
0x000000000000000000000000000000000000000000000000000009184e72a000(10000000000000)
0x0000000000000000000000000000000000000000000000000000000000000064(100)
相当于 (1 + 10000000000000)%100 = 1
执行125后,栈顶变成 0x0000000000000000000000000000000000000000000000000000000000000001.

//crates/interpreter/src/instructions/arithmetic.rs
pub fn addmod&lt;WIRE: InterpreterTypes, H: ?Sized>(context: InstructionContext&lt;'_, H, WIRE>) {
    popn_top!([op1, op2], op3, context.interpreter);
    *op3 = op1.add_mod(op2, *op3)
}

AND

执行到 162 步会遇到 AND 操作.
比较简单就不解释了

// crates/interpreter/src/instructions/bitwise.rs
pub fn bitand&lt;WIRE: InterpreterTypes, H: ?Sized>(context: InstructionContext&lt;'_, H, WIRE>) {
    popn_top!([op1], op2, context.interpreter);
    *op2 = op1 & *op2;
}

SSTORE

将值写入存储槽.

EIP-2200 优化 Gas 消耗,之前重复对一个槽位修改n次会消耗固定Gas * n.之后改成第一次消耗固定Gas,后面的每一次只消耗少部分gas.
BERLIN升级(EIP-2929) 增加了Cold、Warm概念, Address 和 Storage 第一次访问属于 冷访问, Gas消耗会高些,后续访问属于热访问,Gas消耗会少些.

require_non_staticcall 判断当前 CALL 是否是 STATICCALL, STATICCALL 只能访问不能修改数据.
target 要实际修改的合约地址.(CALL和DELEGATECALL的关键就是这里不一样)

每个OpCode都有静态固定Gas消耗,这里是判断是否足够.

gas!(
        context.interpreter,
        context.interpreter.gas_params.sstore_static_gas()
    );

cold_storage_additional_cost 冷访问的额外消耗.
这里这样计算是因为不管冷热都会扣除 WARM_STORAGE_READ_COST,会在其他地方统一扣除WARM_STORAGE_READ_COST,所以这里减去.
COLD_SLOAD_COST = 2100, WARM_STORAGE_READ_COST =100

table[GasId::cold_storage_additional_cost().as_usize()] =
                gas::COLD_SLOAD_COST - gas::WARM_STORAGE_READ_COST;

skip_cold 这里的判断会有些奇怪.正常 Gas不足 是直接报错,这里当参数传入.
这是因为这里保存已加载过的 地址 和 Storage 是在 journal 中,这里并不知道有没有加载过,所以不能直接报错.

pub fn sstore&lt;WIRE: InterpreterTypes, H: Host + ?Sized>(context: InstructionContext&lt;'_, H, WIRE>) {
    require_non_staticcall!(context.interpreter);
    popn!([index, value], context.interpreter);

    let target = context.interpreter.input.target_address();
    let spec_id = context.interpreter.runtime_flag.spec_id();

    if spec_id.is_enabled_in(ISTANBUL)
        && context.interpreter.gas.remaining() &lt;= context.interpreter.gas_params.call_stipend()
    {
        context
            .interpreter
            .halt(InstructionResult::ReentrancySentryOOG);
        return;
    }

    gas!(
        context.interpreter,
        context.interpreter.gas_params.sstore_static_gas()
    );

    let state_load = if spec_id.is_enabled_in(BERLIN) {
        let additional_cold_cost = context
            .interpreter
            .gas_params
            .cold_storage_additional_cost();
        let skip_cold = context.interpreter.gas.remaining() &lt; additional_cold_cost;
        let res = context
            .host
            .sstore_skip_cold_load(target, index, value, skip_cold);
        match res {
            Ok(load) => load,
            Err(LoadError::ColdLoadSkipped) => return context.interpreter.halt_oog(),
            Err(LoadError::DBError) => return context.interpreter.halt_fatal(),
        }
    } else {
        let Some(load) = context.host.sstore(target, index, value) else {
            return context.interpreter.halt_fatal();
        };
        load
    };

    let is_istanbul = spec_id.is_enabled_in(ISTANBUL);

    // dynamic gas
    gas!(
        context.interpreter,
        context.interpreter.gas_params.sstore_dynamic_gas(
            is_istanbul,
            &state_load.data,
            state_load.is_cold
        )
    );

    // refund
    context.interpreter.gas.record_refund(
        context
            .interpreter
            .gas_params
            .sstore_refund(is_istanbul, &state_load.data),
    );
}

后面调用了 sstore_dynamic_gas 进行 动态Gas 计算,这里深入进去看下具体逻辑.
解释在注释里面.

pub fn sstore_dynamic_gas(&self, is_istanbul: bool, vals: &SStoreResult, is_cold: bool) -> u64 {
        // istanbul 升级前的 Gas 计算,历史兼容性,老链就是兼容多.
        if !is_istanbul {
            // 当前值是0,但新值不是0,相当于新建.
            // sstore_set_without_load_cost = SSTORE_SET - SSTORE_RESET = 20000-500
            if vals.is_present_zero() && !vals.is_new_zero() {
                return self.sstore_set_without_load_cost();
            // 其他的情况,包括非0写非0,非0写0
            // sstore_reset_without_cold_load_cost = SSTORE_RESET - ISTANBUL_SLOAD_GAS = 5000 - 800
            } else {
                return self.sstore_reset_without_cold_load_cost();
            }
        }

        let mut gas = 0;

        // 冷访问,第一次访问要额外 + cold_storage_cost(2100)
        if is_cold {
            gas += self.cold_storage_cost();
        }

        // 这里蛮绕的,storage 分三个状态:Original(原始值)、Present(当前值)、New(新值)
        // is_original_eq_present 判断当前值是否等于原始值,判断是否第一次修改
        // new_values_changes_present 判断新写入的值是否真的修改了现值
        // 所以这段就是本次交易中第一次修改槽位的逻辑
        if vals.new_values_changes_present() && vals.is_original_eq_present() {
            // 初始值为0,相当于新写入
            // SSTORE_SET - SSTORE_RESET = 20000 - 5000
            gas += if vals.is_original_zero() {
                self.sstore_set_without_load_cost()
            // 覆盖写入
            // SSTORE_RESET - ISTANBUL_SLOAD_GAS = 5000 - 800
            } else {
                self.sstore_reset_without_cold_load_cost()
            };
        }
        gas
    }

SSTORE 的逻辑继续往下, 到 sstore_refund,进去看下具体逻辑
这是关于 Storage 的退款部分.解释写在注释里.

pub fn sstore_refund(&self, is_istanbul: bool, vals: &SStoreResult) -> i64 {
        // sstore_clearing_slot_refund = 15000 
        let sstore_clearing_slot_refund = self.sstore_clearing_slot_refund() as i64;
        // istanbul 升级前
        if !is_istanbul {
            // 之前非0,新值0,相当于清空槽位,直接返现
            if !vals.is_present_zero() && vals.is_new_zero() {
                return sstore_clearing_slot_refund;
            }
            return 0;
        }
        // 新值和现值相等
        if vals.is_new_eq_present() {
            return 0;
        }
        // istanbul 升级后清空槽位返现要判断本次交易中初始值没有修改过
        // 防止黑客攻击,反复退款
        if vals.is_original_eq_present() && vals.is_new_zero() {
            return sstore_clearing_slot_refund;
        }
        let mut refund = 0;
        // 初始值非0
        if !vals.is_original_zero() {
            // 之前判断过现值(present)和新值(new)是否相等,所以这里新值(new)不为0
            // 也就是这里针对的是original修改为0,然后给你补偿了,但是你又重新写入不为0.
            // 我收回补偿
            if vals.is_present_zero() {
                refund -= sstore_clearing_slot_refund;
            // 就是上面说的你修改new为0,我给你补偿
            } else if vals.is_new_zero() {
                refund += sstore_clearing_slot_refund;
            }
        }
        // 原始值(original)和新值(new)相等的情况
        // 这里有个前提,无论你这次交易中,修改了多少次storage,只要你最后原始值和新值相等.
        // 就认为你没有对状态树造成影响.会给你退还set和reset费用.
        // 这两者的费用在上面的sstore_dynamic_gas最后部分.
        if vals.is_original_eq_new() {
            // 两者为0的情况
            if vals.is_original_zero() {
                refund += self.sstore_set_without_load_cost() as i64;
            // 两者不为0的情况.
            } else {
                refund += self.sstore_reset_without_cold_load_cost() as i64;
            }
        }
        refund
    }

SSTORE 的部分就讲到这里吧,后面再进行总结.

在网站中接着往下运行,碰到了 MSTORE 和 MSTORE8.
MSTORE 我们在前面讲过了, MSTORE8 和 MSTORE 逻辑差不多.
不同的是 MSTORE 写入的是 32 个字节,MSTORE8 写入的是单个字节.
可以自己去看下,这里就不展开了.

SLOAD

从Storage 中加载数据.

虽然功能不同,但实现和SSTORE差不多.就不讲解了.

pub fn sload&lt;WIRE: InterpreterTypes, H: Host + ?Sized>(context: InstructionContext&lt;'_, H, WIRE>) {
    popn_top!([], index, context.interpreter);
    let spec_id = context.interpreter.runtime_flag.spec_id();
    let target = context.interpreter.input.target_address();

    if spec_id.is_enabled_in(BERLIN) {
        let additional_cold_cost = context
            .interpreter
            .gas_params
            .cold_storage_additional_cost();
        let skip_cold = context.interpreter.gas.remaining() &lt; additional_cold_cost;
        let res = context.host.sload_skip_cold_load(target, *index, skip_cold);
        match res {
            Ok(storage) => {
                if storage.is_cold {
                    gas!(context.interpreter, additional_cold_cost);
                }

                *index = storage.data;
            }
            Err(LoadError::ColdLoadSkipped) => context.interpreter.halt_oog(),
            Err(LoadError::DBError) => context.interpreter.halt_fatal(),
        }
    } else {
        let Some(storage) = context.host.sload(target, *index) else {
            return context.interpreter.halt_fatal();
        };
        *index = storage.data;
    };
}

KECCAK256

对内存中的数据进行哈希.
ETH 中的哈希算法,计算地址、哈希校验、Merkle 证明都会使用到它.

网站中执行到 461 步,会碰到它.
看下指令的源码.

要注意,popn_top!([offset], top, context.interpreter)这里 top 是要 hash 数据的长度,不是具体数据.

这里根据要 hash 的数据长度来计算 Gas 消耗.
REVM 中 word 指的是 32 个字节.keccak256_per_word = 6.
这里的计算公式是$$Gas = 6 \times \lceil \frac{len}{32} \rceil$$

gas!(
    context.interpreter,
    context.interpreter.gas_params.keccak256_cost(len)
);
// crates/interpreter/src/gas/params.rs
pub fn keccak256_cost(&self, len: usize) -> u64 {
        self.get(GasId::keccak256_per_word())
            .saturating_mul(num_words(len) as u64)
    }

resize_memory!(context.interpreter, from, len) 避免数据长度不足报错.
keccak256 内部就不深入了.最终调用的 C 写的库.

// crates/interpreter/src/instructions/system.rs
pub fn keccak256&lt;WIRE: InterpreterTypes, H: ?Sized>(context: InstructionContext&lt;'_, H, WIRE>) {
    popn_top!([offset], top, context.interpreter);
    let len = as_usize_or_fail!(context.interpreter, top);
    gas!(
        context.interpreter,
        context.interpreter.gas_params.keccak256_cost(len)
    );
    let hash = if len == 0 {
        KECCAK_EMPTY
    } else {
        let from = as_usize_or_fail!(context.interpreter, offset);
        resize_memory!(context.interpreter, from, len);
        primitives::keccak256(context.interpreter.memory.slice_len(from, len).as_ref())
    };
    *top = hash.into();
}

CALL

用于合约间的调用.

CALL 的时候会传递 7 个参数.从栈顶自上而下

gas, 传递给被调用合约的 GasLimit,最大数值是当前 Frame剩余Gas 的 63 / 64.
addr, 被调用合约的地址.
value 发送给被调用合约的 ETH
argsOffset 传递给被调用函数的参数在内存中的 offset.
argsSize 传递给被调用函数的参数的 size.
retOffset 调用函数返回结果写入内存的 offset.
retSize 调用函数返回结果写入内存的 size

网站中跳到700步.这里对应的源码是

(bool s1, bytes memory r1) = target.call{value: 1 wei}(
    abi.encodeWithSignature("mockFunction(uint256)", 123)
);

栈中自上而下的数据是.

0x0000000000000000000000000000000000000000000000000000000000045417(gas)
0x0000000000000000000000000fb8f3bae4005f8ee539c20e6273b2aac25e5ad2(to)
0x0000000000000000000000000000000000000000000000000000000000000001(value)
0x0000000000000000000000000000000000000000000000000000000000000138(argsOffset)
0x0000000000000000000000000000000000000000000000000000000000000024(argsSize)
0x0000000000000000000000000000000000000000000000000000000000000138(retOffset)
0x0000000000000000000000000000000000000000000000000000000000000000(retSize)

前三个比较明显直接跳过.

argsOffset 数值 138, argsSize 数值0x24(36), 从内存 0x138 的位置读取36个字节.
7b23bd32bf000000000000000000000000000000000000000000000000000000000000007b
7b23bd32bf 是 mockFunction(uint256) 的 abiencode.
后面的 7b 对应的是 123.

retOffset 的数值和 argsOffset 的数值是相同的,这是为了节省 内存 和 Gas.
且两者阶段不一样,不会发生冲突.
retSize 的数值为 0 因为不确定返回的类型,这里直接返回的 bytes,并不能确定长度.

看下 Call 的源码.

在函数开始部分,你会看到这里也会判断 is_static. 正常来说只需要在 STATICCALL 中判断.
为什么在 Call 中也判断 static 的原因是 STATICCALL 的传染性.
如果A合约 STATICCALL B合约, B 合约 CALL C合约, 在整条调用链中执行环境都是 static .即使是 CALL.

get_memory_input_and_out_ranges 获取函数参数和返回值在 memory 中的范围,如果内存不足还会顺便对内存进行扩容,扩容的部分和前面说的 MSTORE 一样.

set_action(InterpreterAction::NewFrame(FrameInput::Call(Box::new())) 涉及到 CALL 和 CREATE 都要返回一个新建 Frame 的动作给上层进行新的调用.

处理函数在 crates/handler/src/evm.rs -> frame_run
和 crates/handler/src/frame.rs -> process_next_action 中.

// crates/interpreter/src/instructions/contract.rs
pub fn call&lt;WIRE: InterpreterTypes, H: Host + ?Sized>(
    mut context: InstructionContext&lt;'_, H, WIRE>,
) {
    popn!([local_gas_limit, to, value], context.interpreter);
    let to = to.into_address();
    let local_gas_limit = u64::try_from(local_gas_limit).unwrap_or(u64::MAX);
    let has_transfer = !value.is_zero();

    if context.interpreter.runtime_flag.is_static() && has_transfer {
        context
            .interpreter
            .halt(InstructionResult::CallNotAllowedInsideStatic);
        return;
    }

    let Some((input, return_memory_offset)) = get_memory_input_and_out_ranges(context.interpreter)
    else {
        return;
    };

    let Some((gas_limit, bytecode, bytecode_hash)) =
        load_acc_and_calc_gas(&mut context, to, has_transfer, true, local_gas_limit)
    else {
        return;
    };

    // Call host to interact with target contract
    context
        .interpreter
        .bytecode
        .set_action(InterpreterAction::NewFrame(FrameInput::Call(Box::new(
            CallInputs {
                input: CallInput::SharedBuffer(input),
                gas_limit,
                target_address: to,
                caller: context.interpreter.input.target_address(),
                bytecode_address: to,
                known_bytecode: Some((bytecode_hash, bytecode)),
                value: CallValue::Transfer(value),
                scheme: CallScheme::Call,
                is_static: context.interpreter.runtime_flag.is_static(),
                return_memory_offset,
            },
        ))));
}

load_acc_and_calc_gas 加载 bytecode 并计算需要本次 CALL 需要的 Limit.
load_account_delegated_handle_error 这里不深入,是加载账户和它的委托账户,不过要处理冷、热账户加载的不同 Gas 消耗

pub fn load_acc_and_calc_gas&lt;H: Host + ?Sized>(
    context: &mut InstructionContext&lt;'_, H, impl InterpreterTypes>,
    to: Address,
    transfers_value: bool,
    create_empty_account: bool,
    stack_gas_limit: u64,
) -> Option&lt;(u64, Bytecode, B256)> {
    // 如果有涉及到转账.A转账给B X ETH
    if transfers_value {
        gas!(
            context.interpreter,
            // 9000
            context.interpreter.gas_params.transfer_value_cost(),
            None
        );
    }

    // 加载账户和它的委托账户.
    let (gas, bytecode, code_hash) =
        load_account_delegated_handle_error(context, to, transfers_value, create_empty_account)?;
    let interpreter = &mut context.interpreter;

    // 记录加载账户和它的委托账户消耗的Gas
    gas!(interpreter, gas, None);

    let interpreter = &mut context.interpreter;

    // EIP-150 升级后CALL 的 GAS 处理
    let mut gas_limit = if interpreter.runtime_flag.spec_id().is_enabled_in(TANGERINE) {
        // 这段相当于 gaslimit - gaslimit /64
        // 就是前面说的将 63/64 的 Gas 传递给CALL
        // 每次CALL之前剩下1/64,是为了避免CALL用完所有的GAS
        // 导致CALLER没有GAS处理剩下的逻辑
        let reduced_gas_limit = interpreter
            .gas_params
            .call_stipend_reduction(interpreter.gas.remaining());
        min(reduced_gas_limit, stack_gas_limit)
    } else {
        stack_gas_limit
    };
    gas!(interpreter, gas_limit, None);

    // 系统对于转账的补贴.赠送给子合约让子合约可以打个Log或者啥.
    if transfers_value {
        gas_limit = gas_limit.saturating_add(interpreter.gas_params.call_stipend());
    }

    Some((gas_limit, bytecode, code_hash))
}

RETURN

函数结束的指令.还会涉及将当前执行帧（Frame）在内存中的返回结果，返回给父调用者.

源码的实现比较简单.
output 从内存中获取要返回的数据.
set_action(InterpreterAction::new_return()) 返回 new_return action.

和其他的 Opcode 不一样,其他大部分的 Opcode 逻辑都直接在对应的函数中写完.
Return 因为涉及到 Frame 之间的调用.所以处理逻辑分开的.

//crates/interpreter/src/instructions/control.rs
pub fn ret&lt;WIRE: InterpreterTypes, H: ?Sized>(context: InstructionContext&lt;'_, H, WIRE>) {
    return_inner(context.interpreter, InstructionResult::Return);
}

fn return_inner(
    interpreter: &mut Interpreter&lt;impl InterpreterTypes>,
    instruction_result: InstructionResult,
) {
    popn!([offset, len], interpreter);
    let len = as_usize_or_fail!(interpreter, len);
    // Important: Offset must be ignored if len is zeros
    let mut output = Bytes::default();
    if len != 0 {
        let offset = as_usize_or_fail!(interpreter, offset);
        if !interpreter.resize_memory(offset, len) {
            return;
        }
        output = interpreter.memory.slice_len(offset, len).to_vec().into()
    }

    interpreter
        .bytecode
        .set_action(InterpreterAction::new_return(
            instruction_result,
            output,
            interpreter.gas,
        ));
}

Return 在返回后具体的处理逻辑在 crates/handler/src/evm.rs->frame_return_result.
主要调用的 return_result,直接跳转进去查看具体逻辑.

free_child_context SharedMemory部分讲过.每个 frame 被创建的时候都会创建 checkpoint,指示 子Frame 的内存从这里开始.这里是将已使用内存的长度设置为 checkpoint.相当于释放了之前 子Frame 占用的内存.
这里只是告诉 SharedMemory 我不再需要那块内存,但是数据还没清理.

match core::mem::replace(ctx.error(), Ok(())) 这段是判断在处理交易过程中,有没有发生错误.

interpreter.return_data.set_buffer(outcome.result.output) 这里就是将 return 返回的数据保存到 interpreter.return_data 中.这里的 interpreter.return_data 是 父frame 的.

let target_len = min(mem_length, returned_len); 这里有个注意的点,记得前面讲 CALL 指令的时候,retSize为 0 吗? 如果 retSize 为 0 , 即mem_length, target_len 也就为0.
retSize为 0 的情况一般是返回类型是返回动态类型,例如bytes之类的.
这些类型并不能提前知道返回的长度,所以直接设置为 0.
如果 retSize = 0 会导致这段中的 [..target_len] 为 [..0],实际并没有拷贝数据到 Frame中专门保存返回数据的内存中.
至于什么时候才会拷贝动态数据的返回类型,后面再说.

if ins_result.is_ok_or_revert() {
    interpreter.gas.erase_cost(out_gas.remaining());
    interpreter
        .memory
        .set(mem_start, &interpreter.return_data.buffer()[..target_len]);
                }
// crates/interpreter/src/gas.rs
pub fn erase_cost(&mut self, returned: u64) {
    self.remaining += returned;
}

interpreter.gas.erase_cost(out_gas.remaining()) 这里是返还未使用的Gas.虽然用的 erase,但是实际是加.看起来误导人所以说下.

create 的部分和 call 差不多,感兴趣的自己看下

// crates/handler/src/evm.rs
fn frame_return_result(
        &mut self,
        result: &lt;Self::Frame as FrameTr>::FrameResult,
    ) -> Result&lt;Option&lt;&lt;Self::Frame as FrameTr>::FrameResult>, ContextDbError&lt;Self::Context>> {
        if self.frame_stack.get().is_finished() {
            self.frame_stack.pop();
        }
        if self.frame_stack.index().is_none() {
            return Ok(Some(result));
        }
        self.frame_stack
            .get()
            .return_result::&lt;_, ContextDbError&lt;Self::Context>>(&mut self.ctx, result)?;
        Ok(None)
    }
// crates/handler/src/frame.rs
pub fn return_result&lt;CTX: ContextTr, ERROR: From&lt;ContextTrDbError&lt;CTX>> + FromStringError>(
        &mut self,
        ctx: &mut CTX,
        result: FrameResult,
    ) -> Result&lt;(), ERROR> {
        self.interpreter.memory.free_child_context();
        match core::mem::replace(ctx.error(), Ok(())) {
            Err(ContextError::Db(e)) => return Err(e.into()),
            Err(ContextError::Custom(e)) => return Err(ERROR::from_string(e)),
            Ok(_) => (),
        }

        // Insert result to the top frame.
        match result {
            FrameResult::Call(outcome) => {
                let out_gas = outcome.gas();
                let ins_result = *outcome.instruction_result();
                let returned_len = outcome.result.output.len();

                let interpreter = &mut self.interpreter;
                let mem_length = outcome.memory_length();
                let mem_start = outcome.memory_start();
                interpreter.return_data.set_buffer(outcome.result.output);

                let target_len = min(mem_length, returned_len);

                if ins_result == InstructionResult::FatalExternalError {
                    panic!("Fatal external error in insert_call_outcome");
                }

                let item = if ins_result.is_ok() {
                    U256::from(1)
                } else {
                    U256::ZERO
                };
                let _ = interpreter.stack.push(item);

                if ins_result.is_ok_or_revert() {
                    interpreter.gas.erase_cost(out_gas.remaining());
                    interpreter
                        .memory
                        .set(mem_start, &interpreter.return_data.buffer()[..target_len]);
                }

                if ins_result.is_ok() {
                    interpreter.gas.record_refund(out_gas.refunded());
                }
            }
            FrameResult::Create(outcome) => {
                let instruction_result = *outcome.instruction_result();
                let interpreter = &mut self.interpreter;

                if instruction_result == InstructionResult::Revert {
                    // Save data to return data buffer if the create reverted
                    interpreter
                        .return_data
                        .set_buffer(outcome.output().to_owned());
                } else {
                    // Otherwise clear it. Note that RETURN opcode should abort.
                    interpreter.return_data.clear();
                };

                assert_ne!(
                    instruction_result,
                    InstructionResult::FatalExternalError,
                    "Fatal external error in insert_eofcreate_outcome"
                );

                let this_gas = &mut interpreter.gas;
                if instruction_result.is_ok_or_revert() {
                    this_gas.erase_cost(outcome.gas().remaining());
                }

                let stack_item = if instruction_result.is_ok() {
                    this_gas.record_refund(outcome.gas().refunded());
                    outcome.address.unwrap_or_default().into_word().into()
                } else {
                    U256::ZERO
                };

                // Safe to push without stack limit check
                let _ = interpreter.stack.push(stack_item);
            }
        }

        Ok(())
    }

在网站中第一个 RETURN 指令在 934 步.
两个参数,分别是返回数据在内存中的 offse t和 size.组合起来对应的数据是 7c.

RETURNDATASIZE

将调用合约后 返回数据 的长度压入栈.

在上面我们说了,返回数据会被拷贝到 context.interpreter.return_data 中.
这里直接返回的这部分的数据长度,没从栈中获取.
因为 子Frame 在 return 的时候已经被释放,数据不存在了,这就是为什么拷贝到 return_data 的原因.

// crates/interpreter/src/instructions/system.rs
pub fn returndatasize&lt;WIRE: InterpreterTypes, H: ?Sized>(context: InstructionContext&lt;'_, H, WIRE>) {
    check!(context.interpreter, BYZANTIUM);
    push!(
        context.interpreter,
        U256::from(context.interpreter.return_data.buffer().len())
    );
}

在网站中执行 939 步就是对应的指令.

RETURNDATACOPY

拷贝合约调用返回数据到指定内存位置.

as_usize_saturated! 宏,将 U256 类型的值转换为 usize 类型，如果数值过大设置为最大值.
其他的源码比较明显,就不讲解了.

看下源码的功能,会感觉 RETURNDATACOPY 和 RETURNDATASIZE 写到 return_result 里面也行.没必要加个 interpreter.return_data 再拷贝.
那为什么还要分出两个指令呢.

对于返回的动态数据,我并不一定需要所有的数据,我可能只需要部分.分成两部分我可以按需拷贝数据.
数据写入内存可能会涉及内存扩容费用,调用部分合约,返回的数据过长时,我可以丢弃,避免内存扩容消耗大量Gas

网站中执行到 968 步,就是对应的指令了.

// crates/interpreter/src/instructions/system.rs
pub fn returndatacopy&lt;WIRE: InterpreterTypes, H: ?Sized>(context: InstructionContext&lt;'_, H, WIRE>) {
    check!(context.interpreter, BYZANTIUM);
    popn!([memory_offset, offset, len], context.interpreter);

    let len = as_usize_or_fail!(context.interpreter, len);
    let data_offset = as_usize_saturated!(offset);

    let data_end = data_offset.saturating_add(len);
    if data_end > context.interpreter.return_data.buffer().len() {
        context.interpreter.halt(InstructionResult::OutOfOffset);
        return;
    }

    let Some(memory_offset) = copy_cost_and_memory_resize(context.interpreter, memory_offset, len)
    else {
        return;
    };

    context.interpreter.memory.set_data(
        memory_offset,
        data_offset,
        len,
        context.interpreter.return_data.buffer(),
    );
}

STATICCALL

合约间调用,和 CALL 功能差不多,但是它不能修改数据.

讲下和 CALL 不同的地方.
STATICCALL 不能传递发送 Value,参数只有相比 CALL 少了 Value.

因为没有 Value,也不能修改数据.
load_acc_and_calc_gas调用时, transfers_value 和 create_empty_account 直接传递 false.

CallInputs 中 is_static 直接传递 true. Value 传递 0.

其他的和 CALL 差不多,就不解释了.

在网站中对应的步数是 1123.

pub fn static_call&lt;WIRE: InterpreterTypes, H: Host + ?Sized>(
    mut context: InstructionContext&lt;'_, H, WIRE>,
) {
    check!(context.interpreter, BYZANTIUM);
    popn!([local_gas_limit, to], context.interpreter);
    let to = Address::from_word(B256::from(to));
    // Max gas limit is not possible in real ethereum situation.
    let local_gas_limit = u64::try_from(local_gas_limit).unwrap_or(u64::MAX);

    let Some((input, return_memory_offset)) = get_memory_input_and_out_ranges(context.interpreter)
    else {
        return;
    };

    let Some((gas_limit, bytecode, bytecode_hash)) =
        load_acc_and_calc_gas(&mut context, to, false, false, local_gas_limit)
    else {
        return;
    };

    // Call host to interact with target contract
    context
        .interpreter
        .bytecode
        .set_action(InterpreterAction::NewFrame(FrameInput::Call(Box::new(
            CallInputs {
                input: CallInput::SharedBuffer(input),
                gas_limit,
                target_address: to,
                caller: context.interpreter.input.target_address(),
                bytecode_address: to,
                known_bytecode: Some((bytecode_hash, bytecode)),
                value: CallValue::Transfer(U256::ZERO),
                scheme: CallScheme::StaticCall,
                is_static: true,
                return_memory_offset,
            },
        ))));
}

DELEGATECALL

合约间调用,和 CALL 功能差不多,但是它的上下文是 CALLER.
它读取修改的是调用发起者的Storage,而不是被调用者的Storage.

讲下和 CALL 不同的地方.
因为上下文是 CALLER 的,所以也不能发送 Value.

load_acc_and_calc_gas调用时, 传入的to 是被调用者的合约地址,而不是CALLER.
所以transfers_value 和 create_empty_account 直接传递 false.

最关键的部分就是 CallInputs 中 target_address, caller, value.

target_address 指示要读取修改Storage 的合约.
在 CALL 中, target_address 是 to, 比较容易理解.

在这里是 context.interpreter.input.target_address().
interpreter.input.target_address指的是 当前Frame 的 target_address,也就是 当前Frame 的要读取修改Storage的合约地址.
相当于保持不变,你在 当前Frame 读取修改的谁,在 子Frame 中也读取修改的谁.

caller 指示调用发起者.
在 CALL 中, caller 是 context.interpreter.input.target_address().
要注意这里用的是target_address.
如果是 当前Frame 是由 CALL 生成的容易理解,如果是 DELEGATECALL 生成的就不同了.
例如 A DELEGATECALL B, B CALL C, B 的 target_address 是 A, 那 C 的 caller 实际是 A, 而不是 B.

在 DELEGATECALL 中, caller 是 context.interpreter.input.caller_address(), 也就是它直接传递 当前Frame 的 CALLER,没进行修改.
例如 EOA 通过 RPC 调用 合约A,A DELEGATE B,B 的 caller 应该是 EOA,而不是 A.
B CALL C, 因为 caller 是 context.interpreter.input.target_address(),也就是A,所以C的caller 是 A

这段很绕,建议你们多看几遍,我自己看了几遍还是觉得绕.
最好画个图.我在纸上画了懒得在这里画.
分清楚当前Frame 的 caller、target_address, 传递给 子Frame 时的 caller、target_address.
是 DELEGATECALL 还是 CALL.

在网站上对应的步数是 1490 步.

pub fn delegate_call&lt;WIRE: InterpreterTypes, H: Host + ?Sized>(
    mut context: InstructionContext&lt;'_, H, WIRE>,
) {
    check!(context.interpreter, HOMESTEAD);
    popn!([local_gas_limit, to], context.interpreter);
    let to = Address::from_word(B256::from(to));
    // Max gas limit is not possible in real ethereum situation.
    let local_gas_limit = u64::try_from(local_gas_limit).unwrap_or(u64::MAX);

    let Some((input, return_memory_offset)) = get_memory_input_and_out_ranges(context.interpreter)
    else {
        return;
    };

    let Some((gas_limit, bytecode, bytecode_hash)) =
        load_acc_and_calc_gas(&mut context, to, false, false, local_gas_limit)
    else {
        return;
    };

    // Call host to interact with target contract
    context
        .interpreter
        .bytecode
        .set_action(InterpreterAction::NewFrame(FrameInput::Call(Box::new(
            CallInputs {
                input: CallInput::SharedBuffer(input),
                gas_limit,
                target_address: context.interpreter.input.target_address(),
                caller: context.interpreter.input.caller_address(),
                bytecode_address: to,
                known_bytecode: Some((bytecode_hash, bytecode)),
                value: CallValue::Apparent(context.interpreter.input.call_value()),
                scheme: CallScheme::DelegateCall,
                is_static: context.interpreter.runtime_flag.is_static(),
                return_memory_offset,
            },
        ))));
}

CREATE / CREATE2

CREATE 和 CREATE2 都是使用给定的代码创建合约.
两个的区别主要是地址的计算不同.
CREATE2 生成的地址是确定的,可以提前预测.

地址计算:
CREATE2: keccak256(0xff + sender_address + salt + keccak256(init_code))[12:]
CREATE: keccak256(rlp([sender_address, sender_nonce]))[12:]

两者调用的同一个函数,用 IS_CREATE2 参数区别是否 CREATE2.

require_non_staticcall!(context.interpreter) 判断是否 STITICCALL.
STITICCALL 不允许修改状态,自然也不允许创建合约.

CREATE 指令接受 3个函数,CREATE2 接受4个参数.
尾部多了一个 salt,用于生成地址.

前3个参数是 value, offset, len

value 发送给创建后的合约的 ETH
offset 合约的 initcode 在内存中的 offset.
len 合约的 initcode 在内存中的 len.

if len != 0 {xxx} 这段是读取 init code 到内存并计算要消耗的Gas.
Gas 按每 32字节进行计算. 每 32字节消耗 2 GasLimit.

刚才扣除的是 inticode 的Gas.

接下来还要扣除 Create 这个操作的基础Gas.
在上面的公式可以看到,CREATE 的地址计算参数类型都是静态参数.
所以 Gas 消耗也是固定消耗,create_cost = 32000.

CREATE2 的计算公式需要 salt 和 init_code. salt 是静态类型, init_code 是动态类型.
所以 Gas 消耗是计算出来的.在 32000 的基础上再加上 keccak256(init_code.len)的消耗.
32000 + 6 * ( len / 32)

call_stipend_reduction 之前说过, CALL 和 CREATE 的时候必须要留 1/64 给 当前Frame处理后续的操作.

你会发现这里并没有计算地址和其他的合约创建操作.
和 CALL 一样,需要返回上层创建新的 Frame 进行操作.

在网站中对应的步数是 1811 步.

pub fn create&lt;WIRE: InterpreterTypes, const IS_CREATE2: bool, H: Host + ?Sized>(
    context: InstructionContext&lt;'_, H, WIRE>,
) {
    require_non_staticcall!(context.interpreter);

    // EIP-1014: Skinny CREATE2
    if IS_CREATE2 {
        check!(context.interpreter, PETERSBURG);
    }

    popn!([value, code_offset, len], context.interpreter);
    let len = as_usize_or_fail!(context.interpreter, len);

    let mut code = Bytes::new();
    if len != 0 {
        if context
            .interpreter
            .runtime_flag
            .spec_id()
            .is_enabled_in(SpecId::SHANGHAI)
        {
            if len > context.host.max_initcode_size() {
                context
                    .interpreter
                    .halt(InstructionResult::CreateInitCodeSizeLimit);
                return;
            }
            gas!(
                context.interpreter,
                context.interpreter.gas_params.initcode_cost(len)
            );
        }

        let code_offset = as_usize_or_fail!(context.interpreter, code_offset);
        resize_memory!(context.interpreter, code_offset, len);

        code = Bytes::copy_from_slice(
            context
                .interpreter
                .memory
                .slice_len(code_offset, len)
                .as_ref(),
        );
    }

    let scheme = if IS_CREATE2 {
        popn!([salt], context.interpreter);
        gas!(
            context.interpreter,
            context.interpreter.gas_params.create2_cost(len)
        );
        CreateScheme::Create2 { salt }
    } else {
        gas!(
            context.interpreter,
            context.interpreter.gas_params.create_cost()
        );
        CreateScheme::Create
    };

    let mut gas_limit = context.interpreter.gas.remaining();

    if context
        .interpreter
        .runtime_flag
        .spec_id()
        .is_enabled_in(SpecId::TANGERINE)
    {
        gas_limit = context
            .interpreter
            .gas_params
            .call_stipend_reduction(gas_limit);
    }
    gas!(context.interpreter, gas_limit);

    context
        .interpreter
        .bytecode
        .set_action(InterpreterAction::NewFrame(FrameInput::Create(Box::new(
            CreateInputs::new(
                context.interpreter.input.target_address(),
                scheme,
                value,
                code,
                gas_limit,
            ),
        ))));
}

下一步在crates/handler/src/frame.rs - > process_next_action中.
然后 match 这里匹配了 NewFrame, 再执行一遍新建 Frame, 走的 make_create_frame.
这部分在前面的流程讲过了,不讲了.

let mut interpreter_result = match next_action {
    InterpreterAction::NewFrame(frame_input) => {
        let depth = self.depth + 1;
        return Ok(ItemOrResult::Item(FrameInit {
            frame_input,
            depth,
            memory: self.interpreter.memory.new_child_context(),
        }));
    }
    InterpreterAction::Return(result) => result,
};

在上面新建的 Frame 执行完成后,又回到 process_next_action.
这次执行到后面的 return_create.
这部分不讲了,感兴趣自己看下.

pub fn return_create&lt;JOURNAL: JournalTr>(
    journal: &mut JOURNAL,
    checkpoint: JournalCheckpoint,
    interpreter_result: &mut InterpreterResult,
    address: Address,
    max_code_size: usize,
    is_eip3541_disabled: bool,
    spec_id: SpecId,
) {
    if !interpreter_result.result.is_ok() {
        journal.checkpoint_revert(checkpoint);
        return;
    }
    if !is_eip3541_disabled
        && spec_id.is_enabled_in(LONDON)
        && interpreter_result.output.first() == Some(&0xEF)
    {
        journal.checkpoint_revert(checkpoint);
        interpreter_result.result = InstructionResult::CreateContractStartingWithEF;
        return;
    }

    if spec_id.is_enabled_in(SPURIOUS_DRAGON) && interpreter_result.output.len() > max_code_size {
        journal.checkpoint_revert(checkpoint);
        interpreter_result.result = InstructionResult::CreateContractSizeLimit;
        return;
    }
    let gas_for_code = interpreter_result.output.len() as u64 * gas::CODEDEPOSIT;
    if !interpreter_result.gas.record_cost(gas_for_code) {
        if spec_id.is_enabled_in(HOMESTEAD) {
            journal.checkpoint_revert(checkpoint);
            interpreter_result.result = InstructionResult::OutOfGas;
            return;
        } else {
            interpreter_result.output = Bytes::new();
        }
    }
    journal.checkpoint_commit();
    let bytecode = Bytecode::new_legacy(interpreter_result.output.clone());
    journal.set_code(address, bytecode);
    interpreter_result.result = InstructionResult::Return;
}

LOG

用于广播链上事件.

逻辑还是比较清晰的,没啥要特别注意的.不讲解了,自己看看.

pub fn log&lt;const N: usize, H: Host + ?Sized>(
    context: InstructionContext&lt;'_, H, impl InterpreterTypes>,
) {
    require_non_staticcall!(context.interpreter);

    popn!([offset, len], context.interpreter);
    let len = as_usize_or_fail!(context.interpreter, len);
    gas!(
        context.interpreter,
        context.interpreter.gas_params.log_cost(N as u8, len as u64)
    );
    let data = if len == 0 {
        Bytes::new()
    } else {
        let offset = as_usize_or_fail!(context.interpreter, offset);
        // Resize memory to fit the data
        resize_memory!(context.interpreter, offset, len);
        Bytes::copy_from_slice(context.interpreter.memory.slice_len(offset, len).as_ref())
    };
    let Some(topics) = context.interpreter.stack.popn::&lt;N>() else {
        context.interpreter.halt_underflow();
        return;
    };

    let log = Log {
        address: context.interpreter.input.target_address(),
        data: LogData::new(topics.into_iter().map(B256::from).collect(), data)
            .expect("LogData should have &lt;=4 topics"),
    };

    context.host.log(log);
}

TSTORE / TLOAD

用于保存和读取瞬态存储.

都是直接调用的 context.host.tstore,这部分内容在前面都讲过,这里也略过.

pub fn tstore&lt;WIRE: InterpreterTypes, H: Host + ?Sized>(context: InstructionContext&lt;'_, H, WIRE>) {
    check!(context.interpreter, CANCUN);
    require_non_staticcall!(context.interpreter);
    popn!([index, value], context.interpreter);

    context
        .host
        .tstore(context.interpreter.input.target_address(), index, value);
}
pub fn tload&lt;WIRE: InterpreterTypes, H: Host + ?Sized>(context: InstructionContext&lt;'_, H, WIRE>) {
    check!(context.interpreter, CANCUN);
    popn_top!([], index, context.interpreter);

    *index = context
        .host
        .tload(context.interpreter.input.target_address(), *index);
}

结束

磨磨蹭蹭终于把文章写完了,写得不是很详细将就着看吧.
写这几篇文章的时候是一边看一边学习理解,看的是源码,还没从整体架构来了解.
讲的也都是正常流程,没深入讲异常处理的部分.
都有点像是在写文档和做翻译了.
后面闲下来继续从稍高点的维度来写写.

加密货币是AI代理的银行

Fri, 20 Mar 2026 01:40:31 +0800

2026年将是AI代理开始成为经济参与者的一年。它们将自主调用SaaS API、执行交易、购买云计算资源并串联工作流。正如人类需要信用卡作为“银行轨道”在现实世界中进行交易一样，代理也需要一个银行——我主张这个银行将基于稳定币。

这个论点分为两部分。首先是“为什么”——为什么加密货币（而不是信用卡）特别适合成为代理的银行层？第二部分是“如何”——假设我们接受加密货币将成为代理的银行层；为了实现这一点，我们究竟需要构建什么？

为什么是加密货币，而不是信用卡？

加密货币社区经常嘲笑信用卡，认为它们根本不适用于代理。这是一种肤浅的看法，可能不准确。Visa等公司在代理商务方面取得了巨大进步——例如，Visa智能商务为代理创建了一个支付网关，类似于Apple Pay的工作方式：

就像Apple Pay一样，这些“代理卡”首先假设你作为人类拥有一张信用卡。
Visa随后会发行一个带有设定限额、授权和有效期条件的“代币化凭证”。就像Apple Pay一样，这些凭证有一个独立的虚拟卡号，你可以安全地提供给你的代理。
当你的代理（例如OpenClaw）使用代币化凭证进行交易时，它会在Visa服务器上解密，链接到你的实际卡片，然后Visa运行支付流程。在整个过程中，加密货币不必参与。Lobster.cash对这种流程有很好的演示。简而言之，代理卡是可行的，有时甚至比加密货币更受欢迎。那么，为什么还要使用加密货币呢？原因有三：(1) 扩展的信任结构，(2) 面向全球受众的互联网原生货币，(3) 新的支付原语。

扩展的信任结构

信用卡——以及由此衍生的代理虚拟卡——具有僵化且固定的“信任结构”。它假设为了进行支付，你始终需要一个经过KYC认证的人类银行账户作为信任的后盾。然后，人类会以父母为孩子开立附属卡的方式，将信任和授权委托给代理。

另一方面，加密货币和稳定币支付不受此类信任假设的限制。虽然你可以（在许多情况下也应该）将稳定币钱包绑定到经过KYC认证的银行账户（如中心化交易所的情况），但你并非必须这样做才能获得支付权限。你可以将稳定币钱包绑定到几乎任何东西——无论是政府ID、社交媒体账户（Google、TikTok、Instagram OAuth）、域名服务器，还是无头智能合约。

许多代理可能会从Lobster.cash和其他与法币关联的信任结构中涌现。但更多代理——例如Conway——将从互联网上法币信任结构之外的其他角落涌现，而稳定币本质上是（可以说是唯一）大规模交易资金的最佳方式。

有句老话——“在互联网上，没人知道你是一条狗”。那么，在加密货币轨道上，没人知道你是一个机器人。

面向全球受R众的互联网原生货币

稳定币是一种面向全球受众的互联网原生货币。支付宝与Qwen的整合，提供奶茶券，展示了代理商务的未来可能是什么样子。如果你在过去十年中在中国生活或访问过，你就会体验到将一种“互联网原生货币”串联到日常应用生态系统（外卖、打车、工资）中的便利。但该系统受地理限制，在一个通过法币权威强制执行的封闭技术生态系统中运行。

另一方面，稳定币从第一天起就是全球性的，可以为世界其他地区提供这种互联网原生货币体验。这对代理来说至关重要，因为它们的第一个自动化工作流将是跨多个司法管辖区和服务提供商的串联SaaS和API调用。一个协调工作流的代理，如果它需要调用美国的LLM端点、欧洲的数据提供商和东南亚的计算集群，它不应该需要三种不同的支付轨道。它只需要一种。

新的支付原语

在这个稳定币支付的世界里，一切都变成了可支付的端点。实际发生的是互联网经济的双重杰文斯悖论——你既增加了可以交易的用户数量（通过给任何人任何东西一个钱包），也增加了每个用户入驻后的交易量（你可以在更多地方结账）。

因为你可以拥有 (1) 扩展的支付方式信任结构，以及 (2) 互联网原生货币，它通过SaaS工作流和全球供应商链连接起来，你很可能会看到新的支付原语的激增。例如，任何创建Dune仪表板的人都可以使用稳定币收取查看请求的费用。

例如，几周前，我在Mistral黑客马拉松上“即兴编写”了Tokker——一个为TikTok创作者服务的品牌管理AI代理。我们通过Privy给它一个稳定币钱包，用于收取它联系的品牌的付款，使付款与TikTok创作者使用的银行方式无关。一个简单的扩展可以是使用同一个稳定币钱包来支付各种计算服务、在线广告服务等等，从而创建一个经济产出的飞轮，你既增加了获得银行服务的人数，也增加了他们在互联网上的消费金额。

如何构建AI银行堆栈？

现在我们对加密货币“为什么”有意义有了基本的理由，我们需要弄清楚“如何”在加密货币轨道上构建这个AI银行堆栈。

在人类世界中，银行扮演着多种角色。它是我们存储、消费、增长和借贷资金的地方。但它也是我们注册身份的地方，是争议解决的中立仲裁者，是防范恶意活动（通过AML）的安全保障。为了为AI代理构建一个银行，我们需要的不仅仅是一个钱包——我们需要一整套保障措施来调解它们与金钱交易的方式。

我相信会有几个相互关联的组件：(1) 身份和授权，(2) 购买流动性，(3) 安全保障，(4) AI代理购买的应用程序“店面”。区块链在所有这四个方面都优于传统轨道。

身份和授权

第一个方面将是身份和授权——谁是正在交易的代理，代理代表谁。这个层面有多种设计。你可以复制Visa的堆栈，创建一个链接到你的法币卡的ID。你也可以将钱包链接到电子邮件或社交媒体。例如，我创建了一个黑客马拉松原型，展示了如何使用电子邮件域名为代理支付创建ZKID。你也可以简单地将代理身份刻录在公共区块链上，如以太坊。这就是ERC 8004等标准在创建“代理注册表”方面的根本作用。

购买流动性

第二个方面是确保代理能够实际支付。钱不会因为你创建了一个稳定币钱包就凭空出现。今天大多数代理平台都“赞助”积分，但这无法大规模持续。法币到加密货币的入口、预融资、先买后付（BNPL）以及其他授权方案将是代理经济中极其重要的一部分。

此外，我们需要确保区块链基础设施实际运行。目前，代理主要在链上进行分级微交易（平均规模为0.09美元）。随着这些交易的规模和交易量的增加，我们需要设计——例如批处理、支付通道、预授权——以确保这些微支付不会堵塞公共区块链。

安全保障

正如银行需要防止恶意行为者洗钱一样，代理银行也需要防止恶意活动，如提示注入、失控的API成本和凭证泄露。巧合的是，区块链领域多年来一直在处理私钥盗窃问题，并开发了一套强大的加密免疫系统——包括可信执行环境（TEE）、多方计算（MPC）和多重签名、零知识证明（ZKP）以及其他保障措施。

我们应该将这些保障措施直接应用于代理支付系统和凭证存储——在许多方面，钱包私钥只是一个更敏感的API密钥，因此整个“私钥”保护堆栈应该被采纳用于代理技能和API凭证，以确保AI代理能够安全地与在线经济互动。

应用程序店面

最后，在应用层，我们正处于代理商务的“应用商店战争”时代。从Merit Systems到ATXP，再到Sponge和Sapiom等提供商，都开发了类似“应用商店”的技能策展机制——允许代理执行从抓取LinkedIn到发送电子邮件和在Hyperliquid上交易等任务。无论是通过电子商务支付现实世界服务，调用按请求付费的SaaS端点，还是自动交易加密代币，代理都需要一个“发现工具”来决定调用哪些端点、使用哪些钱包以及为每项服务支付多少费用。像Coinbase的x402这样的底层协议为代理提供了一种通用的、无需许可的方式来访问现实世界服务，最终使代理能够作为独立的金融参与者积极参与经济。

结论

互联网经济的代理时代才刚刚开始——Claude Code和OpenClaw在不到6个月前才开始流行。在过去十年中，区块链轨道已证明能够支撑一个数十亿美元的链上经济。我相信这两个因素将迅速融合，区块链和稳定币将成为代理经济的银行基石。

AI代理的银行根本不会像银行。它会像一个区块链。

原文链接： x.com/0xfishylosopher/st...

登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～

代理赋能框架的解剖

Fri, 20 Mar 2026 01:40:30 +0800

TLDR: Agent = Model + Harness。Harness 工程是我们围绕模型构建系统以将其转化为工作引擎的方式。模型包含智能，而 Harness 使这种智能变得有用。我们定义了什么是 Harness，并推导出了当今和未来 Agent 所需的核心组件。

何为“Harness”？

Agent = Model + Harness

如果你不是模型，你就是 Harness。

Harness 是除了模型本身之外的所有代码、配置和执行逻辑。一个原始模型并非一个 Agent。但当 Harness 赋予它状态、工具执行、反馈循环和可强制执行的约束时，它就成为了一个 Agent。

具体来说，Harness 包括：

系统提示词（System Prompts）
工具、技能、MCPs 及其描述
捆绑基础设施（文件系统、沙盒、浏览器）
编排逻辑（子 Agent 生成、交接、模型路由）
用于确定性执行的Hook/中间件（压缩、续写、代码检查）

在模型和 Harness 之间划分 Agent 系统的边界有许多复杂的方式。但在我看来，这是最清晰的定义，因为它迫使我们思考如何围绕模型智能设计系统。

本文的其余部分将探讨核心 Harness 组件，并从模型这一核心原语出发，推导出每个组件存在的理由。

从模型的角度看，为什么我们需要 Harness？

有些我们希望 Agent 完成的任务是模型本身无法直接做到的。这就是 Harness 发挥作用的地方。

模型（大多）接收文本、图像、音频、视频等数据，并输出文本。仅此而已。开箱即用，它们无法：

在交互过程中保持持久状态
执行代码
访问实时知识
设置环境并安装包以完成工作

这些都是 Harness 层面的功能。LLM 的结构需要某种机制来封装它们，以完成有用的工作。

例如，为了实现“聊天”这样的产品用户体验，我们将模型封装在一个 while 循环中，以跟踪之前的消息并追加新的用户消息。每个阅读本文的人都使用过这种 Harness。核心思想是，我们希望将期望的 Agent 行为转化为 Harness 中的实际功能。

从期望的 Agent 行为反推 Harness 工程

Harness 工程帮助人类注入有用的先验知识来指导 Agent 行为。随着模型能力越来越强，Harness 被用来精确地扩展和修正模型，以完成以前不可能完成的任务。

我们不会列出所有 Harness 功能的详尽清单。目标是从帮助模型完成有用工作的起点，推导出一组功能。我们将遵循以下模式：

我们想要的行为（或想要修正的行为）→ 帮助模型实现此行为的 Harness 设计。

文件系统：实现持久存储和上下文管理

我们希望 Agent 拥有持久存储，以便与真实数据交互、卸载不适合上下文的信息，并在会话之间持久化工作。

模型只能直接操作其上下文窗口内的知识。在文件系统出现之前，用户必须将内容直接复制/粘贴到模型中，这是一种笨拙的用户体验，并且不适用于自主 Agent。世界已经在使用文件系统来工作，因此模型自然而然地在数十亿个关于如何使用文件系统的 Token 上进行了训练。自然的解决方案是：

Harness 附带文件系统抽象和文件系统操作工具。

文件系统可以说是最基础的 Harness 原语，因为它解锁了以下功能：

Agent 获得一个工作区来读取数据、代码和文档。
工作可以增量添加和卸载，而不是将所有内容保存在上下文中。Agent 可以存储中间输出并维护超出单个会话的状态。
文件系统是一个自然的协作界面。多个 Agent 和人类可以通过共享文件进行协调。Agent 团队等架构依赖于此。

Git 为文件系统添加了版本控制，因此 Agent 可以跟踪工作、回滚错误和分支实验。我们将在下文再次讨论文件系统，因为它被证明是我们需要其他功能的关键 Harness 原语。

Bash + 代码：通用工具

我们希望 Agent 能够自主解决问题，而无需人类预先设计每个工具。

当前主要的 Agent 执行模式是 ReAct 循环，其中模型进行推理，通过工具调用执行一个动作，观察结果，并在一个 while 循环中重复。但 Harness 只能执行它有逻辑的工具。与其强迫用户为每个可能的动作构建工具，更好的解决方案是给 Agent 一个像 Bash 这样的通用工具。

Harness 附带 Bash 工具，因此模型可以通过编写和执行代码自主解决问题。

Bash + 代码执行是让模型拥有计算机并让它们自主解决其余问题迈出的一大步。模型可以即时设计自己的工具，而不是受限于一组固定的预配置工具。

Harness 仍然附带其他工具，但代码执行已成为自主解决问题的默认通用策略。

沙盒和工具：执行与验证工作

Agent 需要一个具有正确默认值的环境，以便它们能够安全地行动、观察结果并取得进展。

我们已经赋予模型存储和执行代码的能力，但所有这些都需要在某个地方发生。在本地运行 Agent 生成的代码是有风险的，单个本地环境无法扩展到大型 Agent 工作负载。

沙盒为 Agent 提供了安全的操作环境。Harness 可以连接到沙盒来运行代码、检查文件、安装依赖项和完成任务，而不是在本地执行。这创建了安全、隔离的代码执行。为了更高的安全性，Harness 可以允许列表命令并强制执行网络隔离。沙盒还解锁了规模化，因为环境可以按需创建、分散到许多任务中，并在工作完成后销毁。

好的环境伴随着好的默认工具。Harness 负责配置工具，以便 Agent 能够完成有用的工作。这包括预安装语言运行时和包、用于 Git 和测试的 CLI、用于 Web 交互和验证的浏览器。

浏览器、日志、截图和测试运行器等工具为 Agent 提供了一种观察和分析其工作的方式。这有助于它们创建自我验证循环，在其中它们可以编写应用程序代码、运行测试、检查日志并修复错误。

模型本身并不会配置自己的执行环境。决定 Agent 在哪里运行、有哪些工具可用、它可以访问什么以及如何验证其工作，这些都是 Harness 层面的设计决策。

记忆与搜索：持续学习

Agent 应该记住它们所看到的内容，并访问在它们训练时不存在的信息。

模型除了其权重和当前上下文中的内容之外，没有额外的知识。在无法编辑模型权重的情况下，“添加知识”的唯一方法是通过上下文注入。

对于记忆，文件系统再次成为核心原语。Harness 支持像 AGENTS.md 这样的记忆文件标准，这些文件在 Agent 启动时被注入到上下文中。当 Agent 添加和编辑此文件时，Harness 会将更新后的文件加载到上下文中。这是一种持续学习的形式，Agent 将一个会话中的知识持久存储并注入到未来的会话中。

知识截止日期意味着模型无法直接访问新数据，例如更新的库版本，除非用户直接提供。对于最新知识，Web 搜索和像 Context7 这样的 MCP 工具帮助 Agent 访问超出知识截止日期之外的信息，例如新的库版本或在训练停止时不存在的当前数据。

Web 搜索和查询最新上下文的工具是嵌入到 Harness 中的有用原语。

应对上下文腐烂（Context Rot）

Agent 的性能不应在工作过程中下降。上下文腐烂（Context Rot）描述了模型随着上下文窗口的填满，在推理和完成任务方面的能力下降。上下文是一种宝贵且稀缺的资源，因此 Harness 需要管理它的策略。

今天的 Harness 在很大程度上是良好上下文工程的交付机制。

压缩（Compaction）

压缩解决了当上下文窗口即将填满时该怎么办的问题。如果没有压缩，当对话超出上下文窗口时会发生什么？一种选择是 API 报错，这不好。Harness 必须为此情况使用某种策略。因此，压缩会智能地卸载和总结现有的上下文窗口，以便 Agent 可以继续工作。

工具调用卸载（Tool Call Offloading）

工具调用卸载有助于减少大型工具输出的影响，这些输出可能会嘈杂地占用上下文窗口，而没有提供有用的信息。Harness 会保留超过阈值 Token 数量的工具输出的开头和结尾 Token，并将完整输出卸载到文件系统，以便模型在需要时可以访问它。

技能（Skills）

技能解决了在 Agent 启动时加载过多工具或 MCP 服务器到上下文中的问题，这会在 Agent 开始工作之前降低性能。技能是一种 Harness 级别的原语，它通过渐进式披露来解决这个问题。模型没有选择在启动时将技能前置信息加载到上下文中，但 Harness 可以支持这一点，以保护模型免受上下文腐烂的影响。

长周期自主执行

我们希望 Agent 能够自主、正确地在长周期内完成复杂的工作。

自主软件创建是编码 Agent 的圣杯。但今天的模型存在过早停止、分解复杂问题困难以及在跨多个上下文窗口工作时缺乏连贯性等问题。一个好的 Harness 必须围绕所有这些问题进行设计。

这就是早期 Harness 原语开始复合的地方。长周期工作需要持久状态、规划、观察和验证，以在多个上下文窗口中持续工作。

文件系统和 Git 用于跟踪工作

文件系统和 Git 用于跟踪跨会话的工作。Agent 在长时间任务中会产生数百万个 Token，因此文件系统持久地捕获工作以跟踪随时间推移的进度。添加 Git 允许新的 Agent 快速了解项目的最新工作和历史记录。对于多个 Agent 协同工作，文件系统也充当共享的工作账本，Agent 可以在其中协作。

Ralph 循环用于持续工作

Ralph 循环是一种 Harness 模式，它通过Hook拦截模型的退出尝试，并在一个干净的上下文窗口中重新注入原始提示，强制 Agent 根据完成目标继续其工作。文件系统使这成为可能，因为每次迭代都以新鲜的上下文开始，但从前一次迭代中读取状态。

规划和自我验证

规划和自我验证以保持正轨。规划是模型将目标分解为一系列步骤的过程。Harness 通过良好的提示和注入提醒如何在文件系统中使用计划文件来支持这一点。在完成每个步骤后，Agent 通过自我验证来检查其工作的正确性。Harness 中的Hook可以运行预定义的测试套件，并在失败时将错误消息反馈给模型，或者可以提示模型独立地自我评估其代码。验证将解决方案建立在测试中，并为自我改进创建反馈信号。

Harness 的未来

模型训练与 Harness 设计的耦合

今天的 Agent 产品，如 Claude Code 和 Codex，都是在模型和 Harness 循环中进行后期训练的。这有助于模型改进 Harness 设计者认为它们应该天生擅长的操作，例如文件系统操作、Bash 执行、规划或使用子 Agent 并行化工作。

这形成了一个反馈循环。有用的原语被发现，添加到 Harness 中，然后用于训练下一代模型。随着这个循环的重复，模型在它们所训练的 Harness 中变得更加强大。

但这种共同演化对泛化能力产生了有趣的副作用。它体现在诸如更改工具逻辑导致模型性能下降等方面。一个很好的例子在 Codex-5.3 提示指南中描述了 apply_patch 工具逻辑用于编辑文件。一个真正智能的模型在不同补丁方法之间切换应该没有太大问题，但在循环中进行 Harness 训练会造成这种过拟合。

但这并不意味着最适合你任务的 Harness 就是模型经过后期训练的那个。Terminal Bench 2.0 排行榜就是一个很好的例子。Claude Code 中的 Opus 4.6 在其他 Harness 中的得分远低于 Opus 4.6。在之前的一篇博客中，我们展示了如何通过仅更改 Harness，将我们的编码 Agent Top 30 提升到 Terminal Bench 2.0 的 Top 5。通过优化 Harness 来完成你的任务，还有很大的提升空间。

Harness 工程的发展方向

随着模型能力越来越强，今天 Harness 中的一些功能将被模型吸收。模型将更好地进行规划、自我验证和长周期连贯性，从而减少上下文注入的需求。

这表明 Harness 的重要性会随着时间的推移而降低。但就像提示工程今天仍然有价值一样，Harness 工程很可能仍然对构建好的 Agent 有用。

诚然，今天的 Harness 弥补了模型的不足，但它们也围绕模型智能设计系统，使其更有效。一个配置良好的环境、正确的工具、持久状态和验证循环，无论其基础智能如何，都能使任何模型更高效。

Harness 工程是一个非常活跃的研究领域，我们用它来改进我们在 LangChain 的 Harness 构建库 deepagents。以下是我们今天正在探索的一些开放且有趣的问题：

协调数百个 Agent 在共享代码库上并行工作
Agent 分析自己的轨迹以识别和修复 Harness 级别的故障模式
Harness 动态地为给定任务即时组装正确的工具和上下文，而不是预先配置

这篇博客旨在定义 Harness 是什么，以及它如何受我们希望模型完成的工作的影响。

模型包含智能，而 Harness 是使这种智能有用的系统。

致敬更多的 Harness 构建，更好的系统，以及更好的 Agent。

原文链接： x.com/Vtrivedy10/status/...

登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～