基于先到先服务的交易排序能否防止抢跑？

最近，已经提出了旨在按先来先服务（FCFS）原则包含交易的共识协议。在本文中，我们探讨了这样的FCFS基础的交易排序是否能够防止在无许可区块链中的抢跑现象。

感谢 Alejo Salles 和 Quintus Kilbourn 对本帖的反馈和审核！

引言与问题陈述

交易提交到内存池的顺序通常不是它们在账本中最终的顺序。术语 最大可提取价值 （MEV）包括通过主动操纵交易的顺序、插入和审查交易来获利的各种方式。抢跑是一种从插入交易中获利的众所周知的方式。抢跑会对去中心化金融应用程序的用户造成负面影响，例如财务损失以及对区块链网络的加载增加。最近，有关旨在以生成的相同顺序包含交易的共识协议的提案出现。在本文中，我们探讨了这样的先来先服务（FCFS）基础的交易排序是否能够防止抢跑，这可以从最近的研究中推断出来123。防止抢跑特别重要，因为如果交易被抢跑，从发送者的角度来看，交易的结果会变得更差，如果能够防止抢跑，那么所谓的三明治攻击（即MEV的另一种形式）也可以得到同样的防止。

在之前的工作基础上12，Kelkar、Deb和Kannan引入了一种共识协议，旨在为无许可区块链3提供基于FCFS的交易排序7。该共识协议保证每个交易 txtxtx 在大型节点投票的情况下，在另一个交易 tx′tx\primetx′ 之前不会出现在最终的账本中。该共识协议在同步通信模型下工作，并将时间离散化为回合，以便在同一回合中到达的交易将获得相同的时间戳。一般来说，同步通信模型用于推理分布式系统中的协议。在同步通信模型中，存在一些时间界限 Δ\DeltaΔ，消息的传递最多可以延迟到这个界限5。作者证明在这种情况下，控制特定比例整体哈希能力的对手无法操纵交易的顺序，这表明抢跑可以完全防止。

然而，我们认为，如果交易在同一回合中并因此接收相同的时间戳，抢跑一笔交易仍然可能。对于现实世界的环境，决定性的问是：一个回合的持续时间11是否可以严格小于创建和分发抢跑交易所需的时间？如果答案是肯定的，基于FCFS的交易排序确实可以防止抢跑。

基于FCFS的交易排序与抢跑

基于FCFS的共识协议保证每个交易 txtxtx 在大型节点投票之前不会出现在最终账本中。我们所看到的主要问题是抢跑者的能力没有得到适当定义（此外，网络和应用程序也没有得到适当建模，而且尚不清楚同一回合中发生的交易应该如何排序）。从上述定义中可以明确的是，抢跑者可能会控制某些节点，利用这些节点来虚假报告交易的顺序。那么其他节点和网络本身呢？我们会假设一个全球化的、类似互联网的网络，节点分散在其中，并且抢跑者的模型非常弱。按照通常的做法，我们假设客户端将交易发送到某些节点，这些节点通过小道消息协议将交易转发到其他节点。抢跑者可能只控制一个节点，基于其他节点的位置选择其在网络中的位置。抢跑者的节点与其他节点保持连接。我们假设抢跑者对网络没有控制（除了选择其节点的位置）。尽管抢跑者被建模为非常弱（可能在现实世界环境中对其而言过于强弱），我们将证明在基于FCFS的共识下仍然可能存在抢跑。

让我们首先可以定义抢跑何时是（不）可能的。如果节点被保证能够区分待抢跑交易来源于前于抢跑交易的时间，防止抢跑是可能的。换句话说，如果抢跑者接收一个待抢跑交易、制作一个抢跑交易并将其发送给（大多数6）节点所需的时间严格大于节点首选获得待抢跑交易的时间，那么抢跑可以完全防止。否则，抢跑是可能的。让我们定义上述因素并将其放入一个好看的公式中：

• dE2Enodesd_{E2E}^{nodes}dE2Enodes​：从发送交易到（大多数）节点接收所需的时间。
• dE2Efront−runnerd_{E2E}^{front-runner}dE2Efront−runner​12：从发送抢跑交易到（大多数）节点接收所需的时间。为简化起见10，我们假设其大约等同于抢跑者接收一个（可能被抢跑的）交易所需的时间。
• dTXd_{TX}dTX​：抢跑者创建抢跑交易所需的时间。
• Δ\DeltaΔ：基于FCFS的共识协议的参数，决定回合的长度。它需要选择得足够大，以确保所有节点在 Δ\DeltaΔ 内接收一笔交易。此外，它还决定节点能够就哪个交易优先于另一个交易达成一致的粒度。

2⋅dE2Efront−runner+dTX−dE2Enodes<Δ⟹front-running possible(1)\tag 1 2 \cdot d_{E2E}^{front-runner} + d_{TX} - d_{E2E}^{nodes} < \Delta \implies \text{front-running possible}2⋅dE2Efront−runner​+dTX​−dE2Enodes​<Δ⟹front-running possible(1)

由于抢跑者在经济上受到了诱导，而其他节点只能承担更高的通信和计算成本，我们假设抢跑者在网络中会选择一个比平均节点更好的位置。通过这样，抢跑者可以比平均节点更早接收交易，并且这些交易也可能被其他节点更早收到。我们大致估计 dE2Efront−runnerd_{E2E}^{front-runner}dE2Efront−runner​ 大约为 50~200 ms，而 dE2Enodesd_{E2E}^{nodes}dE2Enodes​ 大约为 100~1000 ms。创建抢跑交易所需的时间 dTXd_{TX}dTX​ 大致在几毫秒到十几毫秒之间，因为在创建和签署交易前可能需要一些快速分析。 Δ\DeltaΔ 在无许可设置中可能非常大，因为数据包丢失会导致超时，并且重传可能需要较长时间，因此 Δ\DeltaΔ 可能达到分钟级（甚至更长）。将这些粗略估计插入到方程 (1) 得到 [−895 ms,350 ms]<several minutes[-895 \text{ ms}, 350 \text{ ms}] < \text{several minutes}[−895 ms,350 ms]<several minutes. 因此，抢跑显然是可能的。

如果FCFS排序协议得到改进，能够处理（一些）网络间的丢包情况，那么 Δ\DeltaΔ 可显著降低——可能降低到几秒钟的时间。这会使方程 (1) 变为 [−895 ms,350 ms]<several seconds[-895 \text{ ms}, 350 \text{ ms}] < \text{several seconds}[−895 ms,350 ms]<several seconds，凸显抢跑仍然显然是可能的。

如果交易排序的粒度可以从 Δ\DeltaΔ 下降得更低呢？事件的时间排序9 在分布式系统中已经在早期进行了广泛研究13。我们可以利用该环境的结果推断交易排序中的（不）可能。与普遍的看法相反，实际上并不存在节点间共享的无限精确的时间概念。Lundelius和Lynch的不可分割性结果4证明，即使假设所有时钟都有完美的振荡器（即没有时钟漂移），并且节点是诚实且完全相互连接的，也不可能更好地使n个节点的时钟同步。该结果告诉我们的是，端到端延迟的不确定性最终是确定交易排序粒度的决定性因素（而不是最大端到端延迟）——即使所有节点均以诚实方式行事等。在该上下文下，方程 (1) 则变为：

2⋅dE2Efront−runner+dTX−dE2Enodes<ϵ⟹front-running possible(2)\tag 2 2 \cdot d_{E2E}^{front-runner} + d_{TX} - d_{E2E}^{nodes} < \epsilon \implies \text{front-running possible}2⋅dE2Efront−runner​+dTX​−dE2Enodes​<ϵ⟹front-running possible(2)

端到端延迟的不确定性影响着交易的排序，因为当时间差足够小时，节点无法区分交易是稍晚发出还是只是在比其他交易的延迟更大。如果一个节点能够准确顺序交易，那么相应交易的接收时间之间的时间差必须大于端到端延迟的不确定性。如果能够减少不确定性，那么交易就能以更高的粒度排序。端到端延迟的不确定性 ϵ\epsilonϵ 大致在100~300 ms的数量级，并受到路由器缓冲区、交换机缓冲区、操作系统调度程序、不完美的时钟、非对称单向延迟和变化的网络路径等多种因素的影响。为了解释端到端延迟的不确定性有多具挑战性，非直观的是，即使在仅两个直接连接的主机之间，端到端延迟也无法被精确测量。为了精确测量端到端延迟，都必须有完全同步的时钟（这是不可能的）。将端到端延迟不确定性的估计添加到方程 (2) 得到 [−895 ms,350 ms]<[100 ms,300 ms][-895 \text{ ms}, 350 \text{ ms}] < [100 \text{ ms}, 300 \text{ ms}][−895 ms,350 ms]<[100 ms,300 ms]，表明尽管不等式可能对某些值不成立，但它对大多数值是成立的。因此，虽然某些抢跑可以减轻，但抢跑仍无法完全防止——即使我们现在接近理论极限。

抢跑的减轻与预防

基于本文的时间框架，如何提升通过基于FCFS的交易排序来缓解抢跑？

• 端到端延迟不确定性 ϵ\epsilonϵ 可以进一步减小。如果对网络有更多了解或控制，端到端延迟不确定性可以减少。例如，如果知道节点的网络位置，可以大致估计节点之间的物理距离并根据光速作为延迟下限建立节点之间的最小延迟，从而减少端到端延迟不确定性。如果节点的网络环境是受信任并可被控制，网络可能会被建模为概率性的，端到端延迟的不确定性可以进一步减小，但这只有可能在对网络拥有全面控制的许可环境中实现。对网络的了解越多，或对网络的控制能力越强，端到端延迟的不确定性就可以减少——但是，整个环境则变得更加许可和可靠。因此，在无许可设置中，出于减轻抢跑的目的，端到端延迟的减少是受限的。
• 确保 dE2Enodes≈dE2Efront−runner d_{E2E}^{nodes} \approx d_{E2E}^{front-runner}dE2Enodes​≈dE2Efront−runner​，使得抢跑者无法再从其在网络中优于平均的位置中显著受益。这可以通过确保节点（部分）完全互联或者让客户端本身向大多数节点发送交易来实现。这两种方式都会产生显著的通信开销，随节点数量的增加而增加，因此没有规模效应。然而，如果可行，这仍然可以进一步缓解抢跑。方程 (3) 变为 dE2E+dTX<ϵ⟹front-running possible(3)\tag{3} d_{E2E} + d_{TX} < \epsilon \implies \text{front-running possible}dE2E​+dTX​<ϵ⟹front-running possible(3) dE2Ed_{E2E}dE2E​大致可以估计在200~400 ms的顺序。将此估计插入方程 (3) 得到 [205 ms,450 ms]<[100 ms,300 ms][205 \text{ ms}, 450 \text{ ms}] < [100 \text{ ms}, 300 \text{ ms}][205 ms,450 ms]<[100 ms,300 ms]，显示尽管这种减轻在某种程度上是有效的，但仍无法完全防止抢跑。

有效且普遍适用的抢跑减轻显然是一个重大的挑战。但根据我们分析的见解，（如何）才能防止抢跑的出现？

• 如果创建抢跑交易所需的时间 dTXd_{TX}dTX​ 可以增加，则方程 (3) 将立即不再成立。如果 dTX≈ϵd_{TX} \approx \epsilondTX​≈ϵ 的话，这种情况已然成立。为了确保 dTX≈ϵd_{TX} \approx \epsilondTX​≈ϵ，客户端需要提供证明，证明在创建交易后确实已经经过了一定的时间（dTX≳ϵd_{TX} \gtrsim \epsilondTX​≳ϵ）。此外，还需要确保客户端确实在声明的时间点创建了证明，而不是更早。如果这样的结构是可行的，则可以防止抢跑。然而，这样的抢跑防止会带来成本，因为用户体验受到损害，用户必须可证实地等待后才能提交交易。在基于FCFS的交易排序中，额外的等待时间（因此UX成本）可以从约三倍块时间（即在区块链中交易排序的正常粒度）减少到约 ϵ\epsilonϵ。
• 不幸的是，通常增加端到端延迟 dE2Ed_{E2E}dE2E​，这将影响 dE2Efront−runnerd_{E2E}^{front-runner}dE2Efront−runner​ 和 dE2Enodesd_{E2E}^{nodes}dE2Enodes​，并不会有同样的效果，原因是增加 dE2Ed_{E2E}dE2E​ 通常同时会增加端到端延迟的不确定性 ϵ\epsilonϵ。如果 dE2Ed_{E2E}dE2E​ 能显著增大于 ϵ\epsilonϵ，抢跑可能被防止。但在无许可场景下，这似乎并不可行。
• 将交易的内容隐藏在节点中，直到交易的顺序确定，这样就与增加 dE2Ed_{E2E}dE2E​ 的效果相同，而又不增加同时的 ϵ\epsilonϵ。承诺与揭示以及门限加密是隐藏交易内容的两种不同方法。这两种方法同时保证 dE2Enodes≈dE2Efront−runner d_{E2E}^{nodes} \approx d_{E2E}^{front-runner}dE2Enodes​≈dE2Efront−runner​，因此，一个抢跑者无法从其在网络中的优于平均位置中受益。决定因素是在承诺和揭示（或加密和解密）之间的时间，这会将 dE2Ed_{E2E}dE2E​ 增加到足以使方程 (3) 总是不再成立。通过这种方式，单独隐藏交易的内容能够防止抢跑，基于FCFS的交易排序只是减少了承诺与揭示（或加密与解密）之间的时间。

然而，这两种方法都有特定和共同的挑战。承诺与揭示方案引入了所谓的 免费选择问题，这就会激励垃圾消息——如果承诺消息是免费而揭示部分无法被执行，用户就可能投机性地发送承诺消息，仅在对他们有利的情况下才揭示。另一方面，门限加密方案在计算和通信方面面临效率挑战。此外，如何激励门限节点在经济上诱使其诚实，而不是行为不端，仍然是一个开放的研究问题。因此，尽管这两种方法都可以防止抢跑，但它们各自面临特定的挑战，还有一个共同问题，当投资保护交易内容时，不仅考虑抢跑，还考虑到MEV的其他形式时显而易见。某一时刻，交易内容必须揭示，而某个节点具有特权，可以首先看到明文交易，因此也可以是第一个对任何MEV机会（如倒跑或套利）采取行动。所以，尽管隐藏交易内容的相关方法可以防止抢跑，只要保障其具体挑战得到解决，它们仍会限制其他MEV机会的访问到（一或多个）节点，这可能是一种不希望的属性，因为对剩余MEV机会的访问就不再是民主的，而只有一些实体可以获得所有的利润。

讨论与结论

在本文中，我们分析了基于FCFS排序的共识协议是否能够在无许可的互联网环境中防止抢跑。我们表明，基于FCFS的交易排序本身只能在一定程度上减轻抢跑，而无法完全防止——即使在弱抢跑者模型下，其中欠仅控制一个节点。本文强调了抢跑者在网络中的位置的重要性，并阐明了当特权位置受到抑制时，如何改善抢跑的减轻。

基于我们的时间框架，我们讨论了减轻或防止抢跑的多种方式。讨论揭示了防止抢跑的两种方法，即使客户端在其交易被纳入之前可证实地等待，以及隐藏交易内容，为什么它们可能有效，以及它们的缺点。我们讨论了基于FCFS的交易排序如何减少特定的抢跑防止机制的缺点。

最后，端到端延迟的不确定性从根本上限制了节点能够达成一致交易先于另一个交易的粒度。通过将基于FCFS的交易排序集成到共识协议中，能够改进交易的排序粒度。然而，在无许可的现实世界环境中所能达到的粒度如此粗糙，以至于抢跑只有在一定程度上得到缓解，而抢跑机会仍然大量存在。改善可实现的粒度，以使抢跑在很大程度上得到缓解，导致环境更加指定与可信。

感谢阅读，期待你的评论! ⚡ 🤖

1. Mahimna Kelkar et al. “Order-fairness for byzantine consensus”. In: Annual International Cryptology Conference (CRYPTO). Springer. 2020, pp. 451–480. ↩
2. Mahimna Kelkar et al. “Order-Fairness for Byzantine Consensus”. Cryptology ePrint Archive, Report 2020/269. https://ia.cr/2020/269. 2020. ↩
3. Mahimna Kelkar, Soubhik Deb, and Sreeram Kannan. “Order-Fair Consensus in the Permissionless Setting”. Cryptology ePrint Archive, Report 2021/139. https://ia.cr/2021/139. 2021. ↩
4. 作者实际上称之为 fair-ordering，但我们在这里不使用该术语，因为我们认为在MEV的背景下它含糊且可能具有误导性。而是使用 基于FCFS的交易排序，我们认为更为合适。↩
5. Cynthia Dwork, Nancy Lynch, and Larry Stockmeyer. “Consensus in the presence of partial synchrony.”. In: Journal of the ACM (JACM) 35.2 (1988): pp. 288-323. ↩
6. 在同步通信模型中，回合的持续时间由 Δ\DeltaΔ 下界。↩
7. 节点的确切比例取决于FCFS协议的细节。我们在此粗略假设51%的多数。 ↩
8. 请注意， dE2Efront−runnerd_{E2E}^{front-runner}dE2Efront−runner​ 和 dE2Enodesd_{E2E}^{nodes}dE2Enodes​ 并不是独立的。 ↩
9. 接收可抢跑交易的时间可能会比发送抢跑交易所需时间要快，使抢跑变得更简单。 ↩
10. 在上述上下文中，发送交易被视为 事件，而基于FCFS的排序协议的目标是实现这些事件的时间排序。↩
11. Leslie Lamport. “Time, clocks, and the ordering of events in a distributed system”. In: Communications of the ACM, Volume 21, Issue 7. July 1978. pp 558–565 ↩
12. Jennifer Lundelius and Nancy Lynch. “An upper and lower bound for clock synchronization”. In: Information and control 62.2-3 (1984), pp. 190–204. ↩
13. 由于所有节点的观察都受到未知的，可能不相关的延迟不确定性的影响，1中建议的多数投票无法比这些不确定性允许的更好地帮助交易排序——一般来说，多数投票只能在恶意节点行为中的使用，但无法对抗端到端的延迟不确定性。↩

• 原文链接： writings.flashbots.net/f...
• 登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～