Alert Source Discuss
🚧 Stagnant Standards Track: Core

EIP-2593: 以太坊 1.0 链的自动扶梯费用市场变更

Authors Dan Finlay <dan@danfinlay.com>
Created 2020-03-13
Discussion Link https://ethresear.ch/t/another-simple-gas-fee-model-the-escalator-algorithm-from-the-agoric-papers/6399

Table of Contents

简述

当前以太坊中的“第一价格拍卖”费用模型效率低下，并且给用户带来了不必要的成本。本 EIP 提出了一种用允许动态定价交易费用和有效交易价格发现的机制来替代它的方法。

概要

基于 The Agoric Papers。

每个交易都可以选择提供指定“递增”出价的参数，从而创建一个基于时间的拍卖，供验证者包含该交易。

这创造了高效的价格发现，价格将始终立即降至最高出价，而最高出价不一定是用户愿意支付的最高价格。

自动扶梯算法价格图表

动机

以太坊目前使用简单的第一价格拍卖来对交易费用进行定价，这导致了有据可查的效率低下（其中一些记录在 EIP-1559 中），尤其是在价格波动和区块已满时，用户试图估计什么价格才能使交易包含在区块中。

EIP 1559 目前被认为是 Ethereum 协议的一项改进，虽然我同意 gas 市场效率非常低下，但由于这样的更改会影响所有客户端和钱包实现，因此 Ethereum 社区应确保基于可靠的推理和理由做出选择，但我认为 1559 目前缺乏这些。

为了促进对 gas 费用市场进行更有效和具体的讨论，我认为重要的是提出一种明显优于现状的替代方案，以便可以将 EIP-1559 的任何声明的属性与一种可能的改进方案进行比较。

我建议在以下所有条件的组合下比较这三种 gas 支付算法：

  • 常规半满的区块、常规小于半满的区块，以及在一系列令人惊讶的（“黑天鹅”）系列中重复满载的区块。
  • 愿意等待可能低于市场价格的价格的用户，与重视紧急包含并愿意支付高于市场价格的用户。

然后我们应该问：

  • 在给定的情况下，是否愿意支付最多的用户也可能在他们认为可以接受的时间段内处理他们的交易？
  • 想要获得好价格的用户是否可能在合理的时间段内被包括在内？（理想情况下在一个区块内）

我相信，通过这种分析，我们将会发现自动扶梯算法在正常和波动的条件下，对于高风险交易和寻求优惠价格的更休闲的用户来说，都优于 EIP-1559。

虽然我认为应该完成更深入的模拟/分析，但我将分享我在这些条件下的预期结果。

此外，通过引入与当前时间相关的 tx 费用支付，我们为矿工更诚实地报告当前时间创造了激励。

各种条件和算法下的用户策略

首先，我将为正在考虑的不同算法的条件下的不同参与者提出一个可能的最佳策略。

Gas 策略 当前单一价格 EIP 1559 自动扶梯
区块通常半满，用户想要紧急包含。 用户在最近接受的价格范围内出价，可能略微超额支付。 用户在一个价格层级上高于当前价格出价，并且很可能被包括在内。 用户在最近包含的低端到高端范围内出价，并且很可能以尽可能最低的价格被包括在内。
区块通常半满，用户愿意等待好价格。 用户在最近接受的价格的低端或附近出价，可能需要等待一段时间。如果等待时间过长，用户可能需要以更高的价格重新提交。 用户在当前价格层级下或以当前价格层级出价，并且可能会等待价格下跌。如果等待时间过长，用户可能需要以更高的价格重新提交。 用户可以尽可能低地出价，但要设置一个在提高价格之前他们愿意等待的时间上限。
区块通常已满，用户想要紧急包含。 用户在所有最近接受的交易价格之上出价，几乎肯定会大大超额支付。 用户在当前价格层级上出价，并且需要提高他们的 tip 参数才能在下一个区块上具有竞争力，从而重新创建单一价格拍卖的价格问题。 用户以一致接受的价格之上出价，并提供在价格不够高的情况下递增的价格。
区块通常已满，用户愿意等待好价格。 用户在最近接受的价格的低端之下出价，可能需要等待一段时间。如果等待时间过长，用户可能需要以更高的价格重新提交。 用户在当前价格层级下或以当前价格层级出价，并且可能会等待价格下跌。如果等待时间过长，用户可能需要以更高的价格重新提交。 用户可以尽可能低地出价，但要设置一个在提高价格之前他们愿意等待的时间上限。
区块通常未满，用户想要紧急包含。 用户在最近接受的价格范围内或之上出价，可能略微超额支付，并且很可能包含在下一个区块中。 用户在当前价格层级或之上出价，并且很可能包含在下一个区块中。 用户提交在最近接受的价格范围内开始的出价，很可能在下一个区块中被接受。
区块通常未满，用户愿意等待好价格。 用户在最近接受的价格的低端之下出价，可能需要等待一段时间。如果等待时间过长，用户可能需要以更高的价格重新提交。 用户在当前价格层级或之下出价，并且很可能包含在下一个区块中。如果在低价位出价并且等待时间过长，用户可能需要以更高的价格重新提交。 用户可以尽可能低地出价，但要设置一个在提高价格之前他们愿意等待的时间上限，很可能在接下来的几个区块中以尽可能最低的价格被包括在内。

各种条件和算法下的用户结果

现在我将考虑上面列出的策略的最终结果。在这些条件下用户是否满意？我们是否为用户节省了资金？想要紧急包含的用户是否能够确保包含？

Gas 策略 当前单一价格 EIP 1559 自动扶梯
区块通常半满，用户想要紧急包含。 用户支付预期金额，并获得可靠的交易挖掘。 用户支付预期金额，并获得可靠的交易挖掘。 用户支付预期金额，并获得可靠的交易挖掘。
区块通常半满，用户愿意等待好价格。 用户可以等待更好的价格，但可能需要重新提交重新签名的交易。 用户可以等待更好的价格，但可能需要重新提交重新签名的交易。 用户可以通过单个签名在其时间偏好内发现最低价格。
区块通常已满，用户想要紧急包含。 用户超额支付，但可靠地包含交易。 由于 tip 参数在区块内“打破平局”，用户超额支付以获得可靠的包含。 用户能够根据他们需要的紧急程度来平衡他们冒的超额支付金额。
区块通常已满，用户愿意等待好价格。 用户选择他们的价格，并等待它，或手动重新提交。 用户选择他们的价格，并等待它，或手动重新提交。 用户选择他们的最低价格，以及他们的最高价格和最长等待时间，因此无需重新提交。
区块通常未满，用户想要紧急包含。 用户超额支付，但可靠地包含交易。 用户以当前价格层级或之上出价，可靠地挖掘交易。 用户支付预期金额，并获得可靠的交易挖掘。
区块通常未满，用户愿意等待好价格。 用户在最近接受的价格的低端之下出价，可能需要等待一段时间。如果等待时间过长，用户可能需要以更高的价格重新提交。 用户选择他们的价格，并等待它，或手动重新提交。 用户选择他们的最低价格，以及他们的最高价格和最长等待时间，因此无需重新提交。

在所有情况下，我所描述的自动扶梯算法都能够以最佳方式执行。

当前的 gas 拍卖模型在半满和更少的情况下工作良好，但对于有紧急需求的用户，存在超额支付的缺点。对于寻求低价的用户，当前模型存在需要重新提交的缺点，但具有始终为用户提供可靠的区块包含路径的好处。

EIP-1559 在正常条件下也表现良好，但在区块通常已满的条件下，价格发现机制中断，矿工将回退到 TIP 参数来选择要包含的交易，这意味着在网络拥塞的情况下，EIP-1559 迫使用户_要么_选择高效的价格，要么确定下一个区块包含。

EIP-1559 在用户想要支付低于当前市场价格的情况下也存在当前模型的所有重新提交问题，但某些时间限制限制了他们的耐心。自动扶梯算法是此处列出的唯一允许用户根据网络条件和其时间限制发现尽可能最低价格的策略。

规范

客户端范围参数

  • INITIAL_FORK_BLKNUM: 待定

交易参数 交易 gasPrice 参数现在是可选的，如果排除，可以替换为以下参数：

  • START_PRICE: 用户愿意为交易支付的最低价格。
  • START_TIME: 此交易有效的第一个时间。
  • MAX_PRICE: 发送者愿意支付以处理此交易的最高价格。
  • MAX_TIME: 达到用户 MAX_PRICE 的时间。交易在此时间之后保持在该价格有效。

提议

对于所有 block.number >= INITIAL_FORK_BLKNUM 的区块：

当处理具有新定价参数的交易时，矿工现在根据以下线性函数获得费用，其中 BLOCK 是当前区块号：

  • 如果 BLOCK > MAX_TIME，则 TX_FEE = MAX_PRICE。
  • TX_FEE = START_PRICE + ((MAX_PRICE - START_PRICE) / (MAX_TIME - START_TIME) * (BLOCK - START_TIME))

作为 JavaScript 函数：

function txFee (startTime, startPrice, maxTime, maxPrice, currentTime) {
  // 如果当前时间晚于最大时间，则返回最大价格
  if (currentTime >= maxTime) return maxPrice

  const priceRange = maxPrice - startPrice
  const blockRange = maxTime - startTime
  const slope = priceRange / blockRange

  return startPrice + (slope * (currentTime - startTime))
}

向后兼容性

由于当前的 gasPrice 交易实际上是一个固定递增的交易出价，因此它与此模型完全兼容，因此没有具体的要求来弃用当前的交易处理逻辑，从而允许冷钱包和硬件钱包在可预见的未来继续工作。

测试用例

待定

实施

待定

安全考虑

此 EIP 的安全考虑因素是：

  • 目前未知。

版权

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

Citation

Please cite this document as:

Dan Finlay <dan@danfinlay.com>, "EIP-2593: 以太坊 1.0 链的自动扶梯费用市场变更 [DRAFT]," Ethereum Improvement Proposals, no. 2593, March 2020. [Online serial]. Available: https://eips.ethereum.org/EIPS/eip-2593.