ERC-6735: 基于EVM地址的L2别名

识别和转换来自不同 Layer 1、Layer 2 或 Sidechains 的基于 EVM 的地址

摘要

本文档描述了 EVM 地址别名所需的最小业务和技术先决条件、功能和非功能需求，当实施这些需求时，可确保两个或多个 Layer 1、Layer 2 或 Sidechains 可以识别和转换来自不同 Layer 1、Layer 2 或 Sidechains 的基于 EVM 的地址。

动机

由 OASIS 管理的 EEA Communities Project 的 L2 WG 成员已经认识到，对于基于 EVM 的执行框架中的数字资产或外部拥有账户 (EOA) 的地址进行确定性推导（针对 L1、L2、Sidechains），基于资产或地址 EOA 的原始链，称为地址别名，简化了基于 EVM 的 L1、L2 和 Sidechains 之间的互操作性，因为：

• 它允许来自链 A（源链）的消息明确地寻址链 Y 上的资产 A（智能合约）或 EOA（如果资产 A 或 EOA 存在于链 X 和链 Y 上）。
• 它允许用户确定性地验证消息的源链，并且如果需要，可以直接验证资产 A 或 EOA 的原始链及其在原始链上的状态，利用（消息）源链的权威 token 列表。

在基于 EVM 的 L1、L2 和 Sidechains 之间明确且确定性地关联数字资产（智能合约）或外部拥有账户 (EOA) 的地址的能力（其中存在此数字资产或 EOA），也称为地址别名，是基于 EVM 的 L1、L2 和 Sidechains 之间互操作性的关键先决条件。但是，目前没有办法以标准化方式做到这一点——想象一下，每个互联网服务提供商都定义自己的 IP 地址。

因此，由 OASIS 管理的 EEA Communities Project 的 L2 WG（一个开源计划）旨在使本文档基于 root → leaf 的概念建立一个明确且确定性的基于 EVM 的地址别名标准，其中地址别名是基于原始链上的地址和一个偏移量派生的，该偏移量是原始链的一个不可变的特征。

有关带有偏移量的概念性 root → leaf 设计，请参见图 1。

图 1：使用从 L1 到 L2 和 L3 以及返回的链固有的特征的 Root → Leaf 地址别名概念。

图 1 的替代描述：该图概念性地描述了从源链到目标链的（互操作性）消息如何利用地址别名。在底部，一个基于 EVM 的 L1 单向连接到三个基于 EVM 的 L2——A、B 和 C——每个 L2 都有 L1 地址 + L1 偏移量的别名。此外，A 单向连接到 B，别名为 L1 地址 + L1 偏移量 + A 偏移量。B 单向连接到基于 EVM 的 Layer 3 或 L3，别名为 L1 地址 + L1 偏移量 + B 偏移量，表示地址通过 L2 B 锚定在 L1 上。最后，D 通过别名 L1 地址 + L1 偏移量 + B 偏移量加上 D 偏移量单向连接到 C，指示从 L1 到 B 到 D 到 C 的资产监管链。

为了进一步阐明资产可以从 L1 到不同 L2/L3 采用的不同可能路径之间的连接以及该资产的 relativeAddress，我们在红色中视觉上突出了从基于 EVM 的 L1 到 B L2，到 D L3，最后到 C L2 的路径。

图 2：以红色视觉突出显示了从基于 EVM 的 L1 到 B L2，到 D L3，最后到 C L2 的路径。

图 1 的替代描述：该图与图 1 相同。但是，基于 EVM 的 L1 到 L2 B，到 L3 D，最后到 L2 C 之间的单向连接以红色突出显示。

请注意，非 EVM 和基于 EVM 的 L1、L2 和 Sidechains 之间，以及非 EVM 的 L1、L2 和 Sidechains 之间的地址别名不在本文档的范围内。

规范

排版约定：需求 ID

每个需求都由一个唯一 ID 唯一标识，该 ID 由其需求级别后跟需求编号组成，按照约定 [RequirementLevelRequirementNumber]。 有四个需求级别，按照以下约定在需求 ID 中进行编码：

[R] - 以字母 R 开头的 ID 的需求级别应解释为 MUST，如 RFC2119 中所述。
[D] - 以字母 D 开头的 ID 的需求级别应解释为 SHOULD，如 RFC2119 中所述。
[O] - 以字母 O 开头的 ID 的需求级别应解释为 MAY，如 RFC2119 中所述。

请注意，需求在每个需求级别内按升序唯一编号。

示例：应理解为 [R1] 是规范的绝对要求，而 [D1] 是建议，[O1] 是真正的可选。

以下要求仅对基于 EVM 的 L1、L2 或 Sidechains 有效。非 EVM 系统的地址别名不在本文档的范围内。

[R1] 要在链 A 和链 B 之间使用的地址别名——addressAlias——必须按如下方式构造： addressAlias (链 A) = offsetAlias (对于链 A) relativeAddress (在链 A 上) offsetAlias (对于链 A)

[R1] 可测试性：addressAlias 可以使用现有的开源包进行解析和拆分，并将结果与构造中使用的已知 addressAlias 和 relativeAddress 进行比较。

[R2] 链的 offsetAlias 必须是 0xchainId00000000000000000000000000000000chainId

[R2] 可测试性：offsetAlias 可以使用现有的开源包进行解析和拆分，并将结果与构造中使用的已知 chainId 进行比较。

[R3] offsetAlias 中使用的 chainId 不得为零 (0)

[R3] 可测试性：chainId 是一个数值，可以与 0 进行比较。

[R4] offsetAlias 中使用的 chainId 必须是 8 个字节。

[R4] 可测试性：chainId 字符串的长度可以转换为字节，然后与 8 进行比较。

[R5] 如果 chainId 小于 16 位，则 chainId 必须用零填充到 16 位。

例如，Polygon PoS 的 chainId 是 137，当前基于 EVM 的 chainId 列表可在 chainlist.org 找到，其 offsetAlias 是 0x0000000000000137000000000000000000000000000000000000000000000137。

[R5] 可测试性：chainId 可以使用现有的开源包进行解析和拆分，并将结果与构造中使用的已知 chainId 进行比较。随后，可以计算填充中使用的零的数量，并将其与填充的预期零数量进行比较。

[R6] 由于现有 L2 解决方案当前采用此偏移量，因此 Ethereum Mainnet 作为基于 EVM 链的主要锚点的 offsetAlias 必须为 0x1111000000000000000000000000000000001111。

USDC 资产的地址别名的示例为 addressAlias = 0x1111A0b86991c6218b36c1d19D4a2e9Eb0cE3606eB481111

[R6] 可测试性：此要求是 [R1] 的特例。因此，它是可测试的。

[R7] 链上外部拥有账户 (EOA) 或智能合约的 relativeAddress 必须是原始链的智能合约或 EOA 地址，或者是来自另一条链的 EOA 或智能合约的 relativeAddress。

前一个实例的示例是包装后的 USDC 的相对地址 relativeAddress = 0xA0b86991c6218b36c1d19D4a2e9Eb0cE3606eB48，而后一个示例是 Polygon 上包装后的 USDC 的相对地址 relativeAddress = 0x0000000000000137A0b86991c6218b36c1d19D4a2e9Eb0cE3606eB480000000000000137。

最后，从 Ethereum 上的 Arbitrum 向另一个 L1、L2 或 Sidechain 发送包装后的 USDC 消息的地址别名示例为：

addressAlias = 0x0000000000042161A0b86991c6218b36c1d19D4a2e9Eb0cE3606eB480000000000042161

[R7] 可测试性：由于本文档处理的是具有多个实时实现的基于 EVM 的系统，因此有多种已知方法可以验证地址是否属于 EOA 或智能合约。

[R8] addressAlias 中 offsetAlias 的顺序必须从根链的 offSetAlias 开始，括住根链上的 relativeAddress，然后是数字资产存在的链的 offsetAlias 的有序序列。

例如，资产在链 A 上桥接到链 B，然后桥接到链 C，并且将从链 C 桥接到另一条链的有效 addressAlias 将是：

addressAlias = chainId(C) chainId(B) chainId(A) relativeAddress chainId(A) chainId(B) chainId(C)

但是，反向顺序无效：

addressAlias = chainId(A) chainId(B) chainId(C) relativeAddress chainId(C) chainId(B) chainId(A)

[R8] 可测试性：由于 [R1] 是可测试的，并且由于 [R8] 是 [R1] 中的构建顺序规则，可以通过对 [R1] 测试的输出应用逻辑运算来进行测试，因此 [R8] 是可测试的。

请注意，给定顺序可证明正确的证明超出了本文档的范围。

一致性

本节描述了实现与本文档中的要求可证明一致的实现所需的一致性条款和测试。

一致性目标

本文档尚未定义针对所有带有条件 MUST 或 SHOULD 要求的 MUST、SHOULD 和 MAY 要求的带有测试输入的一组标准化测试装置。

一组标准化的测试装置，其中包含所有带有条件 MUST 或 SHOULD 要求的 MUST、SHOULD 和 MAY 要求的测试输入，计划与标准的下一个版本一起发布。

一致性级别

本节指定了此标准的一致性级别。一致性级别为实施者提供了几个一致性级别。这些可用于建立竞争差异。

本文档定义了基于 EVM 的地址别名的一致性级别如下：

• 级别 1： 通过测试报告证明特定实现满足所有 MUST 要求，该报告以易于理解的方式基于特定于实现的测试装置和特定于实现的测试装置输入证明了该实现与每个要求的一致性。
• 级别 2： 通过测试报告证明特定实现满足所有 MUST 和 SHOULD 要求，该报告以易于理解的方式基于特定于实现的测试装置和特定于实现的测试装置输入证明了该实现与每个要求的一致性。
• 级别 3： 通过测试报告证明特定实现满足所有带有条件 MUST 或 SHOULD 要求的 MUST、SHOULD 和 MAY 要求，该报告以易于理解的方式基于特定于实现的测试装置和特定于实现的测试装置输入证明了该实现与每个要求的一致性。

[D1] 声明规范 token 列表实现符合此规范应描述为声明一致性的每个要求执行的测试过程，从而证明该声明与该要求有关。

[D1] 可测试性：由于本文档中每个非一致性目标要求都是可测试的，因此本文档中的所有要求也必须如此。因此，可以存在所有要求的一致性测试，并且可以按照 [D1] 中的要求进行描述。

[R9] 声明规范 token 列表实现在 级别 2 或更高级别符合此规范必须描述为 级别 2 或更高级别的每个要求执行的测试过程，从而证明该声明与该要求有关。

[R9] 可测试性：由于本文档中每个非一致性目标要求都是可测试的，因此本文档中的所有要求也必须如此。因此，可以存在所有要求的一致性测试，可以按照 [R9] 中的要求进行描述、构建和实施，并且可以记录结果。

理由

该标准遵循了从 Ethereum (L1) 到基于 EVM 的 L2（例如 Arbitrum 和 Optimism）以及 L2 之间的地址别名的现有方法，并对其进行了扩展和概括，以允许跨任何类型的基于 EVM 的网络进行别名，而与网络类型无关——L1、L2 或更高层网络。

安全注意事项

数据隐私

该标准未对遵守管辖立法/法规设置任何要求。实施者有责任遵守适用的数据隐私法。

生产准备

该标准未对使用特定应用程序/工具/库等设置任何要求。实施者在选择特定应用程序/工具/库时应进行尽职调查。

在 relativeAddress 的构造中使用 Ethereum 类型地址时，需要考虑安全因素。

如果 relativeAddress 中使用的 Ethereum 类型地址应为 EOA，则目标系统/接收者应验证源帐户的 codehash 是否为 NULL，这样恶意代码就不会在资产转移中秘密执行。

如果 relativeAddress 中使用的 Ethereum 类型地址应该是代表资产的智能合约帐户，则目标系统/接收者应验证源帐户的 codehash 是否与发布的智能合约 solidity 代码的 codehash 匹配，以确保源智能合约按预期运行。

最后，建议作为 relativeAddress 验证的一部分，目标系统执行 ERC-55 中定义的地址校验和验证。

国际化和本地化

鉴于基于 EVM 的地址别名的非语言特定功能，因此没有国际化/本地化方面的考虑。

版权

在 CC0 下放弃版权和相关权利。

Citation

Please cite this document as:

Kelvin Fichter (@smartcontracts), Andreas Freund (@Therecanbeonlyone1969), "ERC-6735: 基于EVM地址的L2别名 [DRAFT]," Ethereum Improvement Proposals, no. 6735, March 2022. [Online serial]. Available: https://eips.ethereum.org/EIPS/eip-6735.