本文讨论了在ePBS（ enshrined Proposer-Builder separation）环境下，bid cancellation这个概念是否还有意义。
以下是翻译后的 Markdown 内容：
在讨论 ePBS 时，经常会出现两个话题。它们是可绕过性（bypassability）和取消投标（bid cancellation）。两者经常一起出现，可能是因为 https://ethresear.ch/t/relays-in-a-post-epbs-world/16278 提出了中继（relay）为构建者（builder）提供服务，即使在 PBS 纳入协议后，构建者可能仍希望继续使用这些服务。因此，取消投标 是这些服务之一，而 可绕过性 是构建者（和提议者）选择不使用该协议的结果。
我认为整个思路显然是有缺陷的，但今天，我只用几行文字来简单地谈谈取消投标，以及它在 ePBS 世界中甚至没有任何意义。
到底什么是取消投标？
那么，为什么构建者想要取消投标呢？要理解这一点，我们需要理解以太坊中区块是如何被“选择”的机制。提议者不会直接联系构建者来询问他们的最佳区块。提议者只是在方便的时候向中继提出请求：“嘿，请给我你现在拥有的最佳投标”。另一方面，构建者无法知道提议者何时会发出这个请求，因此他们不断更新他们的区块，并随着时间的推移提交新的投标。这个拍卖可能需要几秒钟。中继会跟踪从所有构建者那里收到的投标，并在收到请求时将最好的 最后 投标提供给提议者。但是，由于提议者需要时间来向中继请求 payload，因此价格波动可能会将看似有利可图的套利变成亏损。一个已经相应地投标并将此投标发送到中继的构建者，将赶紧取消他们最后的投标，更新他们的区块，删除不良的套利并提交新的投标。这就是所谓的 取消投标。从上面的所有讨论中注意到什么了吗？
一旦投标被提供给提议者，就没有取消了。
实际上，取消只是针对那些尚未被实际请求的投标，它们不在提议者的手中，它们只是在受信任的中继手中。如果在中继提供投标后才取消，提议者不会关心这一点，他们将使用他们已经收到的投标来签署该区块，并将该区块返回给中继。中继被信任会广播和揭示相应的 payload，无论构建者是否提交了延迟取消。
现在，整个机制的存在是因为拍卖的推送性质。中继不是从构建者那里请求投标，而是构建者通过将投标 推送 到中继中来不断更新他们的最后投标。
你需要想象以下两种情况：如果构建者神奇地知道提议者将在何时精确地请求 header 会发生什么？如果沟通不是将投标推送到中继中，而是反过来：中继在需要时从构建者那里请求投标并将其返回给提议者，在这种情况下会发生什么？
两种情况都会导致相同的结果：构建者将根本不会向中继发送无用的投标，他们将等待适当的时间，并在提议者请求之前或被中继要求时相应地发送他们的投标。
在 ePBS 上它会如何改变？
根本不会！就像上面一样，完全一样：
一旦投标被提供给提议者，就没有取消了。
猜猜怎么着，构建者确切地知道提议者何时会要求投标，因为提议者直接请求它。因此，这种情况与上面中继的拉取情况完全相同，当然没有到受信任中继的额外不必要的往返。
构建者的动态是什么？与中继的情况完全相同 他们构建他们的区块，他们保留他们愿意为它投标的金额，如果突然他们的交易变得糟糕，他们不需要烦恼，他们没有向提议者提供任何东西，所以没有必要取消，只需更改区块，删除不良的套利并向下调整投标。
常见问题解答
但是 P2P 上的投标无法取消
当然，但真的吗？谁在乎那些？
如果提议者多次请求呢？
这与今天的情况相同，提议者可以多次询问中继，如果中继决定给出两个不同的 header，则两者都不能取消，提议者可以签署其中任何一个。中继可以决定不提供两次。ePBS 中也是如此。如果提议者询问两次，构建者可以决定不再提供第二次。
我们能阻止构建者被诱骗提供投标吗？
是的，投标可以由提议者签名。
P2P 上的投标
为什么我们关心它们？
现在我已经写得比我想要写的关于这个主题的更多了。让我们考虑 P2P 上的投标的情况。事实上，我们甚至不需要它们。验证者（Validator）可以简单地为了活跃性而进行自我构建（self build）。那么这些投标实现了什么？嗯，它们设置了最低投标，构建者是中心化的参与者，他们只需要超过自己的投标，这可能会迅速演变成一个卡特尔（cartel）。通过在 P2P 上进行投标，我们允许 网络中的任何验证者 设置拍卖的底价。
谁会真正使用它们？
可能有不同的参与者想要使用 P2P 上的投标。
- 关心审查抵抗（censor resistance）和去中心化的家庭 Staker。他们不关心让他们的 EL 工作多一点，并且可能希望每区块提交投标，至少设置底价。这些 Staker 不关心套利，因此他们不关心取消投标，他们甚至没有包括他们自己的交易。
- 希望以任何方式内部化 MEV 的应用程序编写者。你是否为某个 APP 拥有自己的前端？你是否正在运行一个 NFT 铸造，并且你是唯一持有交易的人？嗯，你不需要设置基础设施来成为一个具有 HTTP 端点的大型构建者，也不需要与中间的受信任参与者或其他构建者打交道，只需相应地构建你的区块并通过 P2P 提交你的投标。与上述相同，这些应用程序运行者不关心取消投标，他们是唯一持有铸造 NFT 的交易的人。
注意事项：时机游戏
当然，上面的图景只是其中的一部分，提议者稍后请求 header 以获得更好的投标。中继实际上并没有立即回复，他们在返回之前等待他们能等待的最长时间，以尝试获得更好的投标，等等……在 ePBS 上，这些游戏在某些方面可能会变得更糟，而在另一些方面可能会变得更好。提议者仍然被引诱迟交请求，但现在他们没有太多时间，并且验证者 积极地计算每个对父区块的投票，以支持重组迟到的区块。城镇中的新时机游戏：构建者延迟他们的区块揭示。要判断它将如何影响区块验证的动态还为时过早。
