中继链交易费用和各区块交易限额
资源使用的限制
设置交易费用
根据时间调整交易费用
财政库
前情提要：
在前文Web3研究系列｜Polkadot通证经济学（上），我们详细阐述了
1. 代币DOT的组织架构和主要功能
2. NPoS支付 （NPoS payments）和如何科学地通过罚没（slashing）和销毁 （burn）的方式将通货膨胀率控制在一个合理的范围内，在验证人插槽中的支付细节以及支付分配
正文
中继链交易费用和各区块交易限额
我们希望在中继链交易上实现的一些属性如下：
1. 每个中继链区块都应当给予一定资源，使得块上请求得到有效处理，即便在功能较弱的节点上也是如此，以避免生成区块反应时出现的延迟。
2. 中继链状态（relay chain states）的增长率是受限的。 2’. 如果中继链状态的绝对大小受限，那就更好了。
3. 每个区块对具有一定数量都的操作保证了的可用性和高优先级的交易（例如不当行为报告。）
4. 区块通常远未被填满，因此可以有效地处理活动的峰值，而且拥有较短的包含时间。
5. 费用的变化速度足够缓慢，因此可以在几分钟的时间内准确预测特定交易tx的费用
6. 对于任何交易，其交易费用水平要严格大于区块的生产者为运行它而获得的奖励。否则，将激励区块生产者使用伪造的交易填充区块。
7. 对于任何交易，足够高的运行奖励是区块生产者的共识，且其奖励足以激励包含该交易入块，但又不足以激励区块生产者创建分叉并窃取上一个区块的交易。
实际上，这意味着由于包含额外交易而感到边际报酬高于处理它的相应边际成本，然而，生成完整区块的总报酬并不比生成空块的报酬大多少（即使将tips计算在内）。
目前，我们专注于满足属性1至6（不包含2），并保留属性2和7进行进一步更新。同时我们还需要对属性2进行更多分析。
我们可以通过两种方式来调节中继链块中处理的交易量：施加限制和调整交易费用水平。我们通过对资源使用施加严格的限制来确保满足上面的属性1到3，而属性4到6是通过调整费用来实现的。以下两个小节分别介绍了这两种技术。
资源使用的限制
我们确定了处理交易时可能消耗的四种资源：
1.长度：中继链块中tx的数据大小（以字节为单位），
2. 时间：导入时间（i / o和cpu），
3. 内存：在必要时需运行的内存量
4. 状态：增加的状态存储量。
请注意，与仅消耗一次的其他三个资源不同，状态存储在网络上具有永久成本。因此，对于状态存储，我们可以租用或使用其他运行机制，以更好地将费用与交易的实际成本相匹配，并确保状态大小不受限制。这需要进一步考虑。我们还可以考虑另一种机制，该机制不会对状态增长施加硬性限制，而是通过收费来控制它；但是，我们（WEB3基金会）更喜欢增加健全的限制制度，以避免状态变得无法控制的极端情况出现。
可调参量：目前，我们建议在处理区块时对资源使用进行以下限制。这些参数将通过就目前而言，我们建议在处理块时对资源使用情况进行以下限制。这些参数将通过基于实际数据或更复杂的机制的治理来进一步调整。
1. 长度：5MB，
2. 时间：2s
3. 内存：10GB
4. 状态：1MB 增长
原则上，一个交易会消耗其后三个资源的一定数量，具体取决于它的长度，类型，输入参数和当前状态。但是，为简单起见，我们决定针对每种交易类型仅考虑最坏情况的状态以及其输入参数的字节长度。因此，我们根据长度，类型和参数长度对交易进行分类，并运行测试（基于最坏情况）以检查其典型资源使用情况。
目前，我们正在研究一个模型，区块都能按顺序处理每个交易。因此，为了确保上面区块的内存限制，足以确保每个交易都遵守内存限制。我们确保这一切会如实发生。但是，将来我们可能会考虑并行性。
为了进一步简化模型，我们将定义交易权重作为一个参数来捕捉交易的占用时间和状态增加。具体来说，我们将交易权重定义为其典型时期和状态使用量的最大值，每个权重均按相应区块限制的一部分进行衡量。然后，给定一个交易的集合，我们将一方面求它们的长度之和，另一方面求和它们的权重，并且只有在同时遵守两个限制的情况下，才允许它们在同一块内。这是对资源使用的硬性约束，必须在每个块中都要遵守。
我们在资源使用上增加了进一步的限制。我们将“正常”的交易和“可操作” 交易区别开来，后者属于钓鱼人（fisherman）报告的高优先级交易。仅当其长度之和与权重之和均低于相应限制的75％时，才允许在同一块内收集打包正常交易。这是为了确保每个区块都有用于可操作交易的保证空间（至少留有25％的资源）。
为有关交易建立的典型资源使用细节。通过审查，长度很容易确定。对于时间和内存的使用，我们为中继链准备了最坏的状态（导入该交易类型的时间和内存要求应为最大的状态）。对于给定的交易类型，我们用该状态下需要花费最长的导入时间来生成1万笔交易，并且在Wasm环境中测量资源使用的均值和标准差。如果标准差大于平均值的10％，我们将样本空间增加到10k以上。最后，根据最坏情况的大量交易样本并通过检查来提高状态。
设置交易费用
根据上述模型，我们根据三个参数设置交易费用：交易类型，交易时间长度和权重（已在上文中定义的参数）。这种费用差异用于反映每笔交易产生的资源成本的不同，以此为依据，决定并鼓励或不鼓励某些交易市场行为。
如前所述，一部分交易费需要交给区块生产者，以鼓励包容性，但不是全部，因此，不鼓励区块生产者用虚假的交易填充区块。为简单起见，我们最初建议将每笔交易费用的20％交给区块的生产者，其余80％交给财政库。我们注意到，可以为销毁（burning）设置一个较小的值，但我们选择不这样做是为了更好地控制通货通胀率。 将来，我们可以调整该百分比，并且可以由交易类型而定，以鼓励区块生产者打包特定的交易类型，而无需调整费用。
交易费用的计算公式如下：
其中是与交易无关的参数，它会随着时间的流逝而变化，具体取决于网络流量；我们将在下一部分中解释此参数。参数
仅取决于事务类型；特别是对于业务交易，我们目前将
设置为零。
直观地说，涵盖了区块生产者的处理成本，而
，
涵盖了正在区块内处理一笔交易的机会成本而不是在区块内的另一笔交易。
根据时间调整交易费用
在区块链上，交易需求通常非常不规则。一方面，交易在一天中的数小时或一个月中的数天具有活动高峰。另一方面，存在长期趋势。考虑到这些因素，我们需要一种能够随着时间的推移而自动更新交易费用的机制。根据供求定律，提高费用应减少需求，反之亦然。
为了应对活动高峰，我们需要在迅速提高交易费用或潜在地延长交易包含时间之间进行权衡，这都是不利的影响。我们提出两种机制。第一个非常迅速地调整价格，其速度与活动的高峰和低谷相同。第二个是按照长期趋势缓慢调整，并使用小费给用户提供控制高峰时段等待时间的可能性。我们建议使用带有提示的慢速调整机制，但要提供两种机制的完整性的详细信息。
迅速调整价格
在这种机制下，交易费用会随时间变化很大，但每个区块的所有用户都是固定的（无小费）。
回想一下，我们对块上允许的所有交易的长度和权重之和设置了硬性限制。我们还设置了第二个硬性限制，这一次是“正常” 交易（非操作性交易）的长度和权重之和，等于第一个限制的75％。
定义：我们将区块的饱和度水平（相对于正常交易）定义为介于0到1之间的小数s，它描述了正常交易的极限与饱和的距离。明确地说，块B的饱和度在
的正常长度区间内，正常交易的区块长度限制为总长度限制的75％，正常权重限制为总权重限制的75％。
可调参量：令s*表示目标区块饱和度。这是我们预期的区块饱和度水平的长期平均值（相对于正常交易）。我们最初建议s* = 0.25，以使区块平均充满25％，并且系统可以处理的突发峰值高达正常交易平均数量的4倍。可以根据高峰期间观察到的交易量与平均交易量进行调整，并且通常会在高峰期间会在较高的平均费用，和更长的交易包含时间之间进行权衡。
回想一下，交易费用的计算方式为
与交易无关的。令s为当前区块的饱和度。如果s> s∗，我们会稍微增加流量，如果s <s∗，我们会稍微减少流量。
可调参量：令v为交易费用的变异系数，它控制交易费用调整的速度。我们将从一个区块更新为如下所示：
的模拟，后者又具有以下属性：
假设v的值很小，则参数
的相对变化大约与差（s-s∗）成正比，即
如果有一段时间内产生了k个区块，并且平均饱和度是
，则在此期间
参数的相对变化大约与k乘以差值（average-s∗）成正比。
如何选择变异系数v？假设我们要在k个区块的时间段内，使费用的变化不应超过分数p，即使该时间段内存在100％的饱和度。我们得到公式
如果有一段时间内产生了k个区块，并且平均饱和度是
，则在此期间
参数的相对变化大约与k乘以差值（average-s∗）成正比。
如何选择变异系数v？假设我们要在k个区块的时间段内，使费用的变化不应超过分数p，即使该时间段内存在100％的饱和度。我们得到公式
例如，假设我们检测到在高峰时段某些交易必须等待最多k = 20个区块，如果在此期间费用增加了5％（p = 0.05），我们认为这对用户并不公平。如果s* = 0.25，则上式给出
在这种机制下，费用在短期内几乎保持不变，仅适应长期趋势。我们需要接受这样一个事实，即在峰值期间，包含时间会很长，并且允许交易包含提示，以建立优先包含的市场。
我们使用与上述相同的公式来更新每个区块中的交易费用，即
除非我们选择较小的变异系数v。例如，假设我们希望费用每天最多变化30％，并且一天中产生大约k = 14000个区块。如果s ∗ = 0.25，那么我们得到
交易费用被视为基本价格。交易中会有一个不同的字段，称为“小费（tip）”，用户可以随意在其中放入任何数量的通证或将其保留为零。区块生产者除了获得标准的20％的费用外，还可以获得100％的小费，因此，他们有动力将富含大笔小费的交易收之囊中。这种情况下应该有一款软件可以根据市场情况和交易规模为用户提供有关小费的实时建议。但大多数情况下，应该没有提示。
财政库
该系统需要不断筹集资金，我们称之为财政库（treasury）。这些资金用于支付提供软件更新，应用全民投票决定的任何更改，调整参数并通常保持系统平稳运行的开发人员的费用。
财政库资金以两种方式筹集：
通过铸造新的通证，但会导致通货通胀
通过从取消交易费用和罚没（slashing）通证，否则将被设置为销毁（burning）。
值得注意的是，这些筹集资金的方法模仿了政府筹集资金的传统方式：铸造通货并以税收和罚款控制通货通胀。
我们可以仅通过铸造新的通证来筹集资金，但是我们认为将来自交易费和罚没（slashing）的通证重新导流到财政库是有意义的，否则将被销毁：
通过这样做，我们减少了实际销毁质押（stake burning）的数量，这使我们可以更好地控制通货通胀率（注意，质押销毁stake burning会导致通缩，而我们无法控制或预测导致燃烧的事件）
在发生导致大量质押罚没（stake slashing）的事件之后，如果代码中存在错误或存在有情可原的情况，通常会希望部分偿还被罚没（slashing）的股份。因此，在财政库中使用DOT，比先销毁再铸币更有意义。
假设有一段时间，由于不当行为或交易费用，导致大量罚没质押（stake burning）。这个事实表明系统存在问题，需要修复。因此，这恰好是我们需要更多财政资金来支付开发费用并解决问题的时期。
编译 / 潜行之尧
原文 / WEB3 foundation
