Perils of Parallelism: Transaction Fee Mechanisms under Execution Uncertainty

本文分析了现代区块链中的执行并行性与偶然性如何导致用户激励与调度器激励之间存在固有的权衡,证明了现有费用机制的不可能结果,并提出了一种新的框架,旨在为 Sui 和 Monad 等系统实现公平性与性能的最优边界。

原作者: Sarisht Wadhwa, Aviv Yaish, Fan Zhang, Kartik Nayak

发布于 2026-06-15
📖 1 分钟阅读☕ 轻松阅读

原作者: Sarisht Wadhwa, Aviv Yaish, Fan Zhang, Kartik Nayak

原始论文采用 CC BY 4.0 许可(http://creativecommons.org/licenses/by/4.0/)。 这是对下方论文的AI生成解释。它不是由作者撰写或认可的。如需技术准确性,请参阅原始论文。 阅读完整免责声明

想象一条繁忙的高速公路,不再是车辆逐一在单车道行驶,而是允许交通在多条车道上同时穿梭。这就是现代区块链中的并行执行(Parallel Execution):一种通过同时处理许多交易来提高系统速度的方法。

然而,这篇论文指出,虽然并行高速公路更快,但目前的“收费站”系统(费用机制)是破碎的。它们不知道在司机可能采取不同路线时,该如何公平地收费;也不知道当假司机试图操纵系统时,该如何应对。

以下是使用简单类比对该论文研究结果的拆解。

1. 两个大问题

作者确定了在尝试为并行处理收取费用时会发生的两个主要“危险”(Perils)。

危险 A:“也许”型司机(或有性交易/Contingent Transactions)

想象你正在订购一份定制披萨。你告诉厨房:“我要一份有意大利香肠、蘑菇和橄榄的披萨。”

  • 现实情况: 你实际上只吃了意大利香肠。厨房准备了蘑菇和橄榄,但你并没有碰它们。
  • 问题所在: 在并行区块链中,一笔交易(即披萨订单)通常会说:“我可能需要这 5 个对象(食材)。”但根据世界的当前状态(比如意大利香肠的价格),它最终可能只使用其中 1 个对象。
    • 如果你按“实际使用量”收费: 厨房(调度器)会亏钱,因为他们准备的食材被浪费了。
    • 如果你按“声称要使用的量”收费: 你(用户)会为从未碰过的食材支付过高的费用。

论文的大发现: 你无法兼得。你无法设计出一个既让用户从不多付钱,又让厨房从不因未使用的准备工作而亏损的系统。这在数学上是不可能的。你必须选择由谁来承担风险:是用户还是系统。

危险 B:“假”司机(什一攻击/Shill Attacks)

现在,想象一个根据道路交通量来收费的收费站。

  • 用户的诡计: 一名司机想要支付低廉的过路费。他们向路上发送了一堆虚假的、无用的车辆(什一交易/shill transactions)。这些假车占据了空间,但实际上并不去任何地方。收费站看到“交通拥堵”,从而摊薄了成本,使得真正的司机支付得更少。
  • 收费站的诡计: 运行收费站的人想要赚更多的钱。他们向路上发送自己的假车,让看起来像是真实的司机造成了大规模交通堵塞。随后,收费站就会向真实的司机收取“拥堵费”溢价。

论文的发现: 现有的系统很容易受到这些诡计的影响。如果系统根据正在进行的“并行工作量”来收费,坏人可以通过增加虚假交易来操纵数学模型,从而降低或提高费用。

2. 三种分账方式

由于无法消除未使用食材带来的风险(危险 A),论文建议了三种在用户与系统之间分配账单的方式:

  1. “用户友好型”方案: 你只为你实际吃掉的意大利香肠付费。
    • 结果: 用户很开心(没有多付钱),但厨房(系统)会因为浪费的蘑菇和橄榄而亏损。
  2. “调度器友好型”方案: 即使你只吃了香肠,你也得为整份披萨订单付费。
    • 结果: 厨房很开心(保证了收入),但用户可能会支付过高的费用。
  3. “均摊型”方案: 双方平摊浪费食材的成本。
    • 结果: 这是一种折中方案,双方共同承担“也许”型食材带来的风险。

3. 解决方案:“对象加权”收费站

为了解决“假司机”问题(危险 B)并处理“也许”问题,作者提出了一种名为 OW-TFM(对象加权交易费用机制) 的新系统。

类比:
与其根据现在路上的车辆多少来收费(这可以被伪造),不如想象一种收费系统,它根据昨天某条特定车道的受欢迎程度来收费。

  • 如果某个特定对象(比如某种受欢迎的披萨配料)在上一区块中被频繁使用,那么它在下一个区块的价格会略微上升。
  • 如果它没被使用,价格则保持较低。

为什么这能阻止诡计:

  • 对于用户: 如果你试图通过增加假交易来降低费用,你是做不到的。增加假交易只会增加该对象的用法计数,这可能会提高包括你在内的所有人的费用。你无法通过增加车辆来降低价格。
  • 对于系统: 系统根据过去的数据设定价格,因此它不需要预测未来会发生什么。

4. 底线结论

论文得出结论,构建一个公平、快速且安全的并行区块链非常困难,因为存在一个根本性的权衡:

  • 速度 vs. 公平性: 在实际运行交易之前,你无法完美预测交易会使用哪些“食材”(这会消耗时间,从而违背了并行的初衷)。
  • 安全性 vs. 效率: 你无法同时拥有一个既完美高效(按实际使用量收费)又完美安全(免疫假交易)的系统。

作者建议,区块链设计者(如构建 Sui、Solana 或 Monad 的人)必须明确决定由谁来承担未使用资源的风险(用户或系统),并使用基于历史对象使用情况的定价模型,以防止人们利用假交易来操纵系统。

简而言之: 并行区块链就像一个繁忙的厨房。你无法在知道顾客到底吃了什么之前,就完美地为一顿饭收费;你也无法阻止人们通过假装点餐来搞乱账单。解决方案是:先商定好谁来为浪费的食物买单,然后基于人们“通常”点什么,而不是基于他们“现在说”要点什么来进行定价。

您所在领域的论文太多了?

获取与您研究关键词匹配的最新论文每日摘要——附技术摘要,使用您的语言。

试用 Digest →