Alert Source Discuss
🚧 Stagnant Standards Track: Core

EIP-3534: 受限链上下文类型交易

Authors Isaac Ardis (@whilei)
Created 2021-04-20
Discussion Link https://ethereum-magicians.org/t/eip-3534-restricted-chain-context-transaction-type/6112
Requires EIP-2718, EIP-2930

Table of Contents

简单总结

定义一种新的交易类型，对祖先区块哈希、区块作者和/或区块时间戳施加约束。

摘要

我们引入了一种新的 EIP-2718 交易类型，格式为 0x4 || rlp([chainId, chainContext, nonce, gasPrice, gasLimit, to, value, data, access_list, yParity, senderR, senderS])。

此提案中的 chainContext 元素添加了一个约束，即交易的有效性必须满足所引用值的链段。定义了四种上下文作为此类型的子类：

  • segmentId
  • eligibleMinerList
  • ineligibleMinerList
  • expiry

这些上下文可以以任意组合方式使用。带注释的上下文值组合通过注释上的复合整数前缀来引用。

动机

建立一种基于协议的机制，使交易能够阐明对合格链上下文的约束。 通常，这些约束使消费者（交易者）能够表达关于交易与区块链数据及其来源之间关系的要求。

  • 将交易适用性限制于当前可用且在某些主观视图下进行推理的链上下文。
    • 引入了一种让交易描述对其当前链视图的依赖性的方法。
  • 将交易适用性限制于遵循某个先前区块（及其交易）的链上下文。
    • 引入了一种让交易在“宏观”（区块）级别描述祖先依赖关系的方法。 间接地，这提供了一种让交易依赖于另一笔交易存在的方法，只要依赖交易位于不同的区块中。
  • 将交易适用性限制于受益或未受益于首选/拒绝的矿工地址的区块。
    • 从消费者的角度来看，引入了一个矿工竞争消费者交易的机会/市场；在目前的状态下，当前的矿工-交易处理服务几乎是完全同质的。
  • 限制交易适用时间跨度。
    • 引入了一种（相对于现状）消费者/交易者使交易从交易池中无效/弹出的替代方法。

规范

参数

  • FORK_BLOCK_NUMBER TBD
  • TRANSACTION_TYPE_NUMBER 0x4。 参见 EIP-2718。

从 FORK_BLOCK_NUMBER 开始，引入一个新的 EIP-2718 交易，其 TransactionType 为 TRANSACTION_TYPE_NUMBER。

此交易的 EIP-2718 TransactionPayload 为 rlp([chainId, chainContext, nonce, gasPrice, gasLimit, to, value, data, access_list, yParity, senderR, senderS])。

此交易的 EIP-2718 ReceiptPayload 为 rlp([status, cumulativeGasUsed, logsBloom, logs])。

定义

  • chainContext。 该交易仅对满足所有注解的区块链数据有效。
  • ANNOTATION_COMPOSITE_PREFIX。 一个介于 1 和 0xff 之间的正整数，表示 chainContext 中的子类注解集（即_哪些_链上下文子类应该应用提供的值）。该值应为子类的 ANNOTATION_PREFIX 的总和。
  • ANNOTATION_PREFIX 被定义为子类的八进制派生的正整数，限制为 2^0,2^1,2^2,2^3,2^4,2^5,2^6,2^7 集合。

chainContext 值应采用 ANNOTATION_COMPOSITE_PREFIX || [{subclass value}...] 的形式，其中

  • ... 表示“左侧的零个或多个事物”，以及
  • || 表示字节/字节数组连接运算符。

chainContext 值应编码为 ANNOTATION_COMPOSITE_PREFIX || rlp[{subclass value}...]。

验证

定义为子类的以下值充当特定链上下文的交易有效性的约束。 定义了链上下文不满足的约束的交易应被拒绝为无效。 包含无效交易的区块本身也应被拒绝为无效，按照_现状_处理。

子类组合

注解多个子类引用的 chainContext 值应按以下顺序提供这些值：

  1. ANCESTOR_ID
  2. ELIGIBLE_MINER_LIST
  3. INELIGIBLE_MINER_LIST
  4. EXPIRY

如上所述，ANNOTATION_COMPOSITE_PREFIX 应为指定子类的 ANNOTATION_PREFIX 的总和。

子类

  • ANNOTATION_PREFIX 值用于表示每个可用的上下文子类。

ancestorId

  • ANNOTATION_PREFIX 1。
  • ANCESTOR_ID bytes。 长度介于 4 到 12 字节之间的字节数组。

ANCESTOR_ID 通过连接区块号的字节表示形式及其哈希的前 4 个字节来引用特定区块。 区块号应编码为大端值，并应删除左侧填充的 0。 如果引用创世区块，则可以省略区块号值。

ANCESTOR_ID 值应 RLP 编码为字节数组，用于哈希和传输。

eligibleMinerList

  • ANNOTATION_PREFIX 2。
  • ELIGIBLE_MINER_LIST [address...]。 地址列表。
  • MAX_ELEMENTS 3。 可以提供的最大地址数。

ELIGIBLE_MINER_LIST 值是一个唯一的有效地址数组。 任何包含使用此值的交易的区块都必须包含在此集合中的区块受益人。

ELIGIBLE_MINER_LIST 值的类型应为 [{20 bytes}+]，其中 + 表示“左侧的一个或多个事物”。 不允许使用非唯一值。

ELIGIBLE_MINER_LIST 值应进行 RLP 编码，用于哈希和传输。

ELIGIBLE_MINER_LIST 值不得与 INELIGIBLE_MINER_LIST 值相邻提供。

ineligibleMinerList

  • ANNOTATION_PREFIX 4。
  • INELIGIBLE_MINER_LIST [address...]。 地址列表。
  • MAX_ELEMENTS 3。 可以提供的最大地址数。

INELIGIBLE_MINER_LIST 值是一个唯一的有效地址数组。 任何包含使用此值的交易的区块都不得包含在此集合中的区块受益人。

INELIGIBLE_MINER_LIST 值的类型应为 [{20 bytes}+]，其中 + 表示“左侧的一个或多个事物”。 不允许使用非唯一值。

INELIGIBLE_MINER_LIST 值应进行 RLP 编码，用于哈希和传输。

INELIGIBLE_MINER_LIST 值不得与 ELIGIBLE_MINER_LIST 值相邻提供。

expiry

  • ANNOTATION_PREFIX 8。
  • EXPIRY integer。 正的无符号标量。

EXPIRY 值是一个标量，等于包含此交易的区块的最大有效区块 timestamp。

EXPIRY 值应 RLP 编码为整数，用于哈希和传输。

理由

子类

子类以高度概念独立性定义，可以独立于此 EIP 进行修改和/或扩展。 它们的规范定义允许任意相互 (AND) 组合。

此设计旨在形成一个提案，该提案提供了一组具体的细节，同时具有足够的灵活性以供以后扩展或修改。

ANNOTATION_PREFIX

ANNOTATION_PREFIX 值使用八进制派生值，即 1, 2, 4, 8, 16, 32, 64, 128，遵循一种传统的模式，即从有限的集合中唯一且简洁地表示组合，例如 Unix 样式的文件权限。 此 EIP 定义了八个可能的上下文子类中的四个；这似乎为将来在此方向上的增长留下了充足的空间（如果需要）。 如果满足或超过此限制，则实际上需要进行硬分叉（通过对交易验证方案进行面向共识协议的更改），因此根据需要修改此方案应该是偶然的且微不足道的。

ancestorId

通过按编号和哈希值引用先前的规范区块来约束交易的有效性。 该交易仅在包含在将带注释的区块作为祖先的区块中时才有效。

实际上，“指定的允许链段”可以理解为从 0..ancestorId （包括）的区块段。

chainId 的冗余

可以将此模式理解为 EIP-155 的 chainId 规范的关联项。 EIP155 定义了链之间交易的限制；将任何 EIP-155 交易的应用限制为具有带注释的 ChainID 的链。 ancestorId 进一步限制了交易应用到一个链的一个小节（“段”）。

从这个约束层次结构中，我们注意到 ancestorId 的实现可以使 chainId 在概念上变得冗余。

那么为什么要保留 chainId？

chainId 被维护为一个不变量，因为：

  • 使用此 EIP 提出的交易类型是可选的，这意味着在协议基础设施和工具中继续需要 chainId 来处理遗留和其他交易类型。
  • 此 EIP 提出的交易类型中 ancestorId 的存在是可选的。如果 RCC 交易未填充该值，则对 chainId 的需求仍然存在。
  • chainId 值不一定与 ancestorId 冗余，尤其是在分叉导致活动链的情况下。例如，对区块 1_919_999 的 ancestorId 引用在以太坊和以太坊经典之间将是模棱两可的。
  • 可以指定在使用 ancestorId 的情况下省略 chainId。这将增加基础设施的复杂性，以便删除 chainId 通常需要的几个字节；我们认为这种权衡是不值得的。
    • chainId 在交易签名方案中用作 v 值（对于 v,r,s）；删除或修改此值会在低于编码交易字段的级别上产生复杂性，从而需要额外的基础设施复杂性来实现。
  • ancestorId 的提议设计没有提供完美的精确度（以节省字节大小为代价）。 在值模糊不清的小概率事件中，chainId 保持了交易链特异性的绝对保证。

eligibleMinerList

仅当包含在具有包含在带注释的地址列表中的 etherbase 的区块中时，该交易才有效。 将“白名单”(eligibleMinerList) 与“黑名单”(ineligibleMinerList) 结合使用在逻辑上是不一致的；不允许它们的组合。

选择 MAX_ELEMENTS 限制为 3，以平衡限制交易潜在大小的利益，并为用户提供足够的表达水平。在撰写本文时，以太坊的前 3 名矿工（按区块，按已知的公共地址衡量）占所有产生的区块的 52%。

ineligibleMinerList

仅当包含在 etherbase _未_包含在带注释的地址列表中的区块中时，该交易才有效。 将“黑名单”(ineligibleMinerList) 与“白名单”(eligibleMinerList) 结合使用在逻辑上是不一致的；不允许它们的组合。

选择 MAX_ELEMENTS 限制为 3，以平衡限制交易潜在大小的利益，并为用户提供足够的表达水平。在撰写本文时，以太坊的前 3 名矿工（按区块，按已知的公共地址衡量）占所有产生的区块的 52%。

expiry

仅当包含在具有小于带注释值的 timestamp 的区块中时，该交易才有效。 使用正整数是因为它对应于指定的区块 timestamp 标头值的类型。

子类组合

由于子类对 ANNOTATION_PREFIX 使用基于八进制的值，因此可以将它们区分开地组合为总和，只要我们假设注释基数（即排序）。 例如：

  • ANNOTATION_PREFIX 1 专门表示 ancestorId。
  • ANNOTATION_PREFIX 2 专门表示 eligibleMinerList。
  • ANNOTATION_PREFIX 4 专门表示 ineligibleMinerList。
  • ANNOTATION_PREFIX 8 专门表示 expiry。
  • ANNOTATION_PREFIX 1+2=3 组合 ancestorId 和 eligibleMinerList。
  • ANNOTATION_PREFIX 1+4=5 组合 ancestorId 和 ineligibleMinerList。
  • ANNOTATION_PREFIX 1+8=9 组合 ancestorId 和 expiry。
  • ANNOTATION_PREFIX 1+2+8=11 组合 ancestorId 和 eligibleMinerList 和 expiry。
  • ANNOTATION_PREFIX 1+4+8=13 组合 ancestorId 和 ineligibleMinerList 和 expiry。
  • ANNOTATION_PREFIX 2+4=6 不允许。它将组合 eligibleMinerList 和 ineligibleMinerList。
  • ANNOTATION_PREFIX 1+2+4+8=15 不允许。它将组合 eligibleMinerList 和 ineligibleMinerList（以及 ancestorId 和 expiry）。

由于排序是为多个值定义和要求的，因此带注释的引用仍然可以区分。例如：

  • chainContext 3[e4e1c0e78b1ec3,[Df7D7e053933b5cC24372f878c90E62dADAD5d42]] - 交易只能包含在一个块号为 15_000_000 且哈希以字节 e78b1ec3 开头的规范祖先块中，并且如果包含块使用 Df7D7e053933b5cC24372f878c90E62dADAD5d42 作为受益人。
  • chainContext 10[[Df7D7e053933b5cC24372f878c90E62dADAD5d42],1619008030] - 交易只能包含在一个将 Df7D7e053933b5cC24372f878c90E62dADAD5d42 命名为受益人的区块中，并且该区块的时间戳大于 1619008030（CDT 2021 年 4 月 21 日星期三 07:27:10）。

EIP-2930 继承

EIP-2930 可选访问列表类型交易 用作此提案的假定“基本”交易类型。 但是，这 不是 概念上的依赖关系；此提案中包含的 accessList 部分（这是与 EIP-155 后的遗留交易字段的唯一区别）可以很容易地删除。 站在 EIP-2930 的肩膀上只是为了支持和进一步采用下一代交易。

签名目标

签名会覆盖交易类型以及交易数据。 这样做是为了确保交易不能被“重新解释”为不同类型的交易。

向后兼容性

没有已知的向后兼容性问题。

测试用例

段 ID 区块号 规范区块哈希
e78b1ec3 0 0xe78b1ec31bcb535548ce4b6ef384deccad1e7dc599817b65ab5124eeaaee3e58
01e78b1ec3 1 0xe78b1ec31bcb535548ce4b6ef384deccad1e7dc599817b65ab5124eeaaee3e58
e4e1c0e78b1ec3 15_000_000 0xe78b1ec31bcb535548ce4b6ef384deccad1e7dc599817b65ab5124eeaaee3e58
e8d4a50fffe78b1ec3 999_999_999_999 0xe78b1ec31bcb535548ce4b6ef384deccad1e7dc599817b65ab5124eeaaee3e58
7fffffffffffffffe78b1ec3 9223372036854775807 0xe78b1ec31bcb535548ce4b6ef384deccad1e7dc599817b65ab5124eeaaee3e58

更多测试用例，待办事项。

安全注意事项

为什么 ancestorId 的 4 个字节的区块哈希“足够安全”

摘要: 无效 ancestorId 的机会大约为 40 亿到 400 亿分之一，故意复制场景的机会更大，例如恶意重组。

如果确实发生冲突，这意味着交易在两个段上都有效（与现状下一样）。

选择四个字节而不是整个哈希（32 个字节）只是为了减少实现该值所需的跨线传输的信息量。 使用整个哈希将导致“完美安全”的实现，并且每增加一个字节都会呈指数级降低冲突的机会。

ancestorId 的目标是将一个链段与另一个链段区分开来，并通过这样做，使交易能够以足够的精度定义它需要位于哪个链上。 当交易的 ancestorId 引用一个区块时，我们希望非常确定该引用不会与交易作者想到的区块不同的区块混淆。

我们假设抗冲突性的特征统一适用于区块哈希值的所有可能子集，因此我们首选使用_前_ 4 个字节是任意的，并且在功能上等同于任何其他长度相等的子集。

为了便于阅读和访问，以下参数将引用 4 个字节的十六进制表示形式，其长度为 8 个字符，例如 e78b1ec3。

冲突的 ancestorId 的机会是 1/(16^8=4_294_967_296) 倍，我们认为在（备用链上的）存在等效编号的区块的机会是什么。假设任何给定区块都有公共叔块的概率为 10%（1/10），这产生了 (1/(16^8=4_294_967_296) * 1/10。请注意，这个概率假设“正常”的链和网络行为。在持久的竞争链段的情况下，该值上升到 100% (1)。

eligibleMinerList

未发现自己列在带注释的 eligibleMinerList 中的矿工应立即从其交易池中删除该交易。

在悲观的前景中，我们还应该期望这些不合格的节点不会提供这些交易的重新广播，这可能会影响交易向其预期矿工的分配（和可用性）。另一方面，矿工有动力让自己可以接收此类交易，并且在网络上和网络外都有许多可行的方法。

使用 eligibleMinerList 的交易的作者必须假设此类交易的区块链状态数据库的“一般可用性”将低于非限制性交易（因为只有一部分矿工能够处理该交易）。

最后一个考虑因素是白名单矿工关于白名单交易和没有白名单交易的处理顺序的经济学。 没有白名单的交易乍一看似乎更具竞争力，因此应该优先处理。 但是，遵循这种策略的矿工可能会发现他们的声誉下降，并且在最坏的情况下，会看到交易作者的断言偏好转移到他们的竞争对手以及超出他们的范围。

ineligibleMinerList

除了上面 eligibleMinerList 提出的担忧之外，ineligibleMinerList 还有一个独特的担忧：为了使矿工实体避免被黑名单禁止，他们只需要使用备用的临时地址作为区块受益人。 原则上，这是不可避免的。

但是，矿工“躲避”的相关成本应考虑在内。

  • 创建帐户需要时间和精力。但实际上，这项工作可以在任何方便的时间和环境下完成。可能边缘化，但非零。
  • 从多个帐户转移资金需要相应数量的交易。区块奖励在交易处理后应用，因此矿工无法在他们挖掘的同一区块中同步将资金从临时帐户转移到目标帐户（否则这将是“免费”交易）。
  • 通过使用一个临时地址来躲避黑名单，矿工也可能导致他们不符合当时的白名单交易的资格。

验证成本

矿工列表和过期时间取决于易于缓存和上下文可用的条件（即包含区块头）。预期强制执行这些验证的基础设施开销成本将是名义上的。

ancestorId 的验证需要断言按区块号命中的正数据库（从而交叉引用存储的区块哈希值）。 这种必要的查找可以（并且可能已经）被缓存，但我们必须期望缓存值的命中率低于 100%，因为查找值是任意的。 但是，考虑到这一点，使用深度 ancestorId 的交易的值越来越小，因此我们应该期望 大多数使用此字段的交易都使用一组相对较小的常见、浅层的、对缓存友好的值。

交易规模增加

建议的附加字段可能会增加交易规模。 建议的字段与任何 gas 成本无关，因此没有为潜在的垃圾邮件建立协议定义的经济缓解措施。 但是，矿工认为不希望的交易可以简单地从交易池中删除并忽略。

版权

通过 CC0 放弃版权和相关权利。

Citation

Please cite this document as:

Isaac Ardis (@whilei), "EIP-3534: 受限链上下文类型交易 [DRAFT]," Ethereum Improvement Proposals, no. 3534, April 2021. [Online serial]. Available: https://eips.ethereum.org/EIPS/eip-3534.