Builder Codes & ERC-8021：修复链上归属问题

TL;DR: Base 正在构建一个全球性的链上飞轮：构建者创建应用，应用驱动交易用户，而交易用户扩大市场以吸引更多的构建者。为了加速这个循环，我们需要衡量和奖励那些产生真正价值的应用。ERC-8021 和 Builder Codes 提供了这个缺失的层：一个让应用证明其链上影响并因其产生的交易获得信用的系统。

归因差距

虽然任何人都可以将交易链接到特定的协议，但确定哪个应用促成了交易是很困难的。

协议是用户直接交互的链上智能合约。例如：像 Aerodrome 这样的去中心化交易所或像 Morpho 这样的借贷协议。

应用是驱动任何用例交易的链下实体。例如：Web 和移动界面、交易机器人和后端自动化。

协议很容易追踪，因为所有交互数据都公开存在于链上。然而，应用与其促成的交易没有原生链接。

这种差距有实际的后果。没有归因数据，链就无法衡量哪些应用为生态系统带来价值。注意力、分配和资本投资的分配变成了手动猜测，而不是数据驱动的决策。Builder Codes 和 ERC-8021 弥合了这种归因差距，并使构建者能够以更开放和透明的方式竞争资源。

行业灵感

其他人已经独立地认识到并解决了他们生态系统中的这个问题，但没有以一种每个人都可以重用的方式。

Hyperliquid 开创了“Builder Codes”这个术语，允许应用注释交易以获得产生互换费用的一部分，从而创建可衡量的激励对齐，并奖励驱动真实交易量的应用。

Polymarket 紧随其后，实现了类似的方法，应用可以通过其订单簿 API 来注释交易，以获得奖励资格。

这两种解决方案在其生态系统内都运行良好，但它们仅限于特定的用例（Hyperliquid 用于永续合约，Polymarket 用于预测市场）。为了使交易归因在整个 Ethereum 上起作用，我们需要一个通用标准，任何协议都可以采用。

ERC-8021：Ethereum 的交易归因

我们编写了 ERC-8021 以便今天能够在 Ethereum 上归因 任何 交易。为此，我们必须在几个约束条件下工作：

1. 它需要与 Ethereum 现有的交易格式一起使用。 这通过与现有代码和工具保持互操作性，从而能够为节点和应用快速发布。

2. 无论交易试图做什么，它都需要工作。 这使我们能够为所有协议提供服务而无需集成工作，并建立开发者网络效应。

数据后缀

为了满足这些约束，我们利用了一个未充分利用的 EVM 属性：智能合约忽略超出预期函数参数附加的额外数据。如果你在函数参数之后使用任何附加数据调用智能合约函数，默认情况下，它们将被安全地丢弃而不会出现错误或回滚。由于此“数据后缀”在不影响执行的情况下通过，因此我们可以安全地进行归因，并适用于任何交易类型。

以下是它在实践中的样子：

智能合约仅读取 abi 编码数据 (0xabcd...1234) 以执行交互。归因数据后缀 (0xaaaaaaaaaaaa) 在不影响执行的情况下通过，但仍可在交易数据中用于分析。

这种模式并不新鲜。许多团队已经在生产中大规模地使用它，包括 Aerodrome、Morpho 和 Base App。

一直缺少的是标准化。每个团队都实现自己的格式，因此很难跨不同的应用解析归因。ERC-8021 通过定义一个规范的数据后缀来解决这个问题。该标准支持常规交易和 ERC-4337 用户操作，确保与所有钱包类型兼容。

标准化数据后缀模式

ERC-8021 通过解决三个核心问题来构建其模式：互操作性、可扩展性和身份。让我们从第一性原理推导出格式。

问题 1：互操作性

现有的归因方法在互操作性检测方面存在困难。虽然特定的应用可以附加一个他们知道要查找的自定义数据后缀，但另一方如何辨别交易数据是否以归因结尾？如果没有标准标记，每个解析器都需要为每种归因格式定制逻辑。

ERC-8021 通过在每个数据后缀的末尾添加一个常量标记来解决这个问题：0x80218021802180218021802180218021（重复 16 字节的“8021”）。这使解析器能够通过检查最后 16 个字节是否与标准标记匹配来可靠地检测是否存在归因。与此特定 16 字节序列意外冲突的概率极低（1/2^128），使其成为一种可靠的检测机制。

ercMarker = 0x80218021802180218021802180218021
attributionData = 0xaaaaaaaaaaaa
dataSuffix = attributionData + ercMarker
           = 0xaaaaaaaaaaaa80218021802180218021802180218021

问题 2：可扩展性

归因需求会不断发展。今天的格式可能无法满足未来新归因类型、更高效编码、额外元数据字段等的用例。我们需要一种版本控制机制，以便在不破坏现有实现的情况下进行迭代。

ERC-8021 在 ercMarker 之前立即添加一个字节的 schemaId，以标识如何解析其他前面的 schemaData。这单个字节提供了 256 个可能的模式版本，每个版本定义了如何解析实际的归因数据。

ercMarker = 0x80218021802180218021802180218021
schemaId = 0x00
schemaData = 0xaaaaaaaaaaaa
dataSuffix = schemaData + schemaId + ercMarker
           = 0xaaaaaaaaaaaa0080218021802180218021802180218021

后缀旨在从 calldata 的末尾向后解析：

1. 提取最后 16 个字节 → 验证 ercMarker 是否与标准匹配

2. 提取前一个字节 → 切换 schemaId 以确定解析规则

3. 根据模式规范解析剩余字节

问题 3：身份

为了使归因有用，它需要帮助识别谁应该为交易获得信用。现有的用于标识的候选项是 Ethereum 地址、应用名称和网站域名，但它们中的每一个都在一个重要的属性上妥协。理想的标识符应该小巧，并且可以根据需要链接到其他信息。

ERC-8021 选择“代码”作为基于字符串的标识符（例如“abc123”）。代码对于开发者来说很熟悉，可以映射到传统应用中的推荐代码等概念，并且对于调试来说具有人类可读性。

ERC-8021 还定义了一个代码注册表智能合约，可以在其中注册代码，并从中读取其其他相关信息，通常分为链上或链下元数据。

链上元数据 支持协议奖励。协议可以查询应将记入代码的奖励发送到何处。例如，DEX 可以奖励产生最多交易的前端。

链下元数据 支持应用发现。通过将代码与应用名称和域名相关联，我们创建了一个生态系统的透明视图。公共仪表板可以显示按交易量排名的顶级应用，将链上使用数据转化为用户查找新应用的分发渠道。

任何人都可以部署自己的代码注册表，只要它遵守标准化接口即可。不同的生态系统可以运行自己的具有自定义规则的注册表，同时仍然使其他人能够解析归因并查询相关信息。

interface ICodeRegistry {
    /// @notice 返回协议应向其发送奖励的地址
    /// @dev 这使任何人都可以向驱动交易量的应用分发奖励
        function payoutAddress(string memory code) external view returns (address);

    /// @notice 返回一个 URI 以获取链下元数据（应用名称、网站、徽标）
    /// @dev 这支持构建发现界面和排行榜
    function codeURI(string memory code) external view returns (string memory);

    /// @notice 检查代码是否符合格式规则（字符集、长度约束）
    /// @dev 解析器使用它来过滤格式错误的数据
    function isValidCode(string memory code) external view returns (bool);

    /// @notice 验证代码是否已注册
    function isRegistered(string memory code) external view returns (bool);
}

端到端流程

让我们演练一下 ERC-8021 在实践中是如何工作的，从注册到事务提交和解析。

步骤 1：注册代码

应用使用唯一的代码注册表注册一个代码（例如，“baseapp”）。注册表存储链上元数据和指向代码的链下元数据的指针。

步骤 2：编码数据后缀

在准备交易时，第一个应用将其代码注入到 ERC-8021 数据后缀中（下面的真实示例）：

ercMarker = 0x80218021802180218021802180218021
schemaId = 0x00
codesLength = 7
codes = ["baseapp"]
schemaData = codes.join(",") + codesLength
           = 0x6261736561707007
dataSuffix = schemaData + schemaId + ercMarker
           = 0x62617365617070070080218021802180218021802180218021

步骤 3：将数据后缀附加到交易数据

然后，应用将此数据后缀附加到交易数据：

transaction.data = abiEncodedData + dataSuffix
                 = 0xabcd...1234 + 0x62617365617070070080218021802180218021802180218021
                 = 0xabcd...123462617365617070070080218021802180218021802180218021

步骤 4：像往常一样提交交易

准备好交易后，可以由应用直接签名和提交，或者通过提示用户使用他们的钱包来执行此操作。

步骤 5：解析和归因

在链上确认交易后，分析工具会解析其数据以进行归因：

1. 检查最后 16 个字节的 ercMarker → 确认 ERC-8021 格式

2. 读取 schemaId 字节 → 确定解析规则

3. （在此示例中，给定模式 0）提取代码长度和代码数组 → "baseapp"

4. 查询注册表以获取与 ”baseapp” 代码匹配的支付地址和元数据

结果：整个 Ethereum 上通用的、可互操作的交易归因。通过阅读 官方规范 了解更多信息。

Base Builder Codes

Base 旨在使每笔交易都通过 ERC-8021 进行归因，以便告知我们如何优先考虑我们的注意力、分配、投资资本以及对那些发展 Base 全球经济的团队的奖励。

为了实现这一目标，我们推出了 Base Builder Codes：第一个 ERC-8021 代码注册表。选择加入并将其 Base Builder Codes 附加到其交易的应用可以在我们的 公共排行榜上显示。任何人都可以立即通过 base.dev 免费声明 Base Builder Code。

Base 生态系统中的几个关键合作伙伴已经同意在 Base 上实施 ERC-8021 构建者代码，以帮助缩小归因差距：Aerodrome、Avantis、Bitget、Clanker、Definitive、Flaunch、Hydrex、Jumper、Kyber、Limitless、Maestro、Mamo、Moonwell、o1、PancakeSwap、Privy、Rips、Sigma、Slab、Sport.Fun、Swissborg、Treble、Turnkey、Virtuals 等。

有关我们的智能合约实现的更多详细信息，请阅读 github.com/base/builder-codes。

集成 Base Builder Codes

集成 Base Builder Codes 会影响你准备交易的方式，并且可能影响你提交交易的方式，具体取决于你的应用使用的钱包堆栈。

通常应用可以通过三种钱包类型提交交易：

1. 通用钱包：用户带来的第三方体验（例如，Base App、MetaMask）

2. 嵌入式钱包：由应用为每个用户配置（例如，Privy、CDP Embedded Wallet）

3. 服务器钱包：由应用的服务器端独立管理（例如，Turnkey、CDP Server Wallet）

如果你是钱包提供商：你需要提供一种让应用自定义交易数据的方法。对于通用钱包，这可能意味着使用 dataSuffix 功能实现 ERC-5792 的 wallet_sendCalls。对于嵌入式和服务器钱包，这可能意味着确保应用可以通过你的 API 和 SDK 手动附加到交易。ERC-4337 帐户可能需要额外的工作来支持用户操作的数据后缀附加。在此处阅读更多内容 here。

如果你是应用：集成路径取决于你的钱包模型。可以直接控制签名的应用（嵌入式或服务器钱包）可以手动附加数据后缀。使用通用钱包的应用依赖于 wallet_sendCalls 中的 dataSuffix 功能。在此处阅读更多内容 here。

与通用钱包的前端集成

这些应用使用户能够自带钱包来验证身份并使用链上资金。用户通过 Web 弹出窗口、浏览器扩展程序、移动钱包等进行连接。

应用通过标准化的钱包 API 使用通用钱包提交交易。钱包可以自定义它们如何向用户呈现这些请求、促进签名和交易提交。我们建议使用带有 dataSuffix 功能的 wallet_sendCalls 方法：

// Sample ERC-8021 attribution  for "baseapp" from earlier
// 来自之前的“baseapp”的示例 ERC-8021 归因
const response = await provider.request({
  method: 'wallet_sendCalls',
  params: [{\
    calls: [{\
      to: protocolAddress,\
      data: encodedCalldata,\
      value: '0x0'\
    }],\
    capabilities: {\
      dataSuffix: {\
        value: '0x62617365617070070080218021802180218021802180218021'\
        optional: true\
      }\
    }\
  }]
});

我们还建议使用 Wagmi 库来获得便利，你可以在其中指定默认的 dataSuffix 以自动应用于你的交易请求。

与嵌入式钱包的前端集成

这些应用使用户能够以隐形的方式接收和使用钱包，同时保留一定程度的非托管所有权。用户使用传统的链下方法（例如，电话号码、电子邮件）登录，并且通常将他们的帐户视为绑定到该应用。

应用通过其提供商的 SDK 和/或 API 使用嵌入式钱包提交交易。由于应用可以控制交易签名，因此你可以手动将数据后缀附加到交易数据并直接签名。大多数嵌入式钱包 SDK 现在直接在其界面中支持 dataSuffix 参数。

例如，你可以参考 Coinbase 和 Privy 的这些指南。

与服务端钱包的后端集成

这些应用直接从自己的服务器进行交易，通常密钥由第三方提供商管理。

应用通过其提供商的 SDK 和/或 API 使用服务器钱包提交交易。这与嵌入式钱包的工作方式几乎相同：在签名和发送之前，将你的 ERC-8021 格式化后缀附加到交易数据。

立即开始归因

全球可归因且受到奖励的链上经济的基础就在这里。ERC-8021 和 Base Builder Codes 是识别产生真正价值的应用的缺失层。

缩小应用的归因差距，接入 Base 飞轮，并展示你对链上经济的贡献。

立即在 base.dev 声明你的 Base Builder Code 并开始归因。我们期待看到你构建的内容！

更多资源：

• ERC-8021 标准：eip.tools/eip/8021

• Base Builder Codes：github.com/base/builder-codes

• 集成指南：docs.base.org/base-chain/quickstart/builder-codes

来自 Base 工程博客的更多内容

\ \ Base Engineering Blog\ \ Jun 12\ \ Engineering the Commerce Payments Protocol Powering Shopify\ \ Launching a new standard for scalable, trust-minimized commerce \ \ Base Engineering Blog\ \ May 15\ \ We’re making Base 10x faster with Flashblocks\ \ Bringing near-instant responsiveness to apps on Base Mainnet. \ \ Base Engineering Blog\ \ Dec 18\ \ Scaling Base With Reth\ \ Unlocking the future of Base

View more

• 原文链接： blog.base.dev/builder-co...
• 登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～