State Lock 拍卖：迈向协作区块建设
非常感谢Quintus 、 Louis和Shea的讨论和评论为本文提供了灵感。
概述
由于MEV-Boost 拍卖的公开首价性质，搜索者有动力进行垂直整合，成为“搜索者构建者”，以“更具战略性”出价。这种旨在在 MEV-Boost 拍卖中获得优势的垂直化产生了不幸的后果，即大大提高了统计套利的进入壁垒，并因此造成了不利的市场结构，新的“搜索者构建者”在其中从其他建设者处批量购买订单流，并补贴区块作为有效的“广告支出”，以达到与现有区块建设者的订单流平价。消除“战略投标”这一优势的尝试主要集中在将拍卖修改为密封投标格式，但所有这些都未能实现，因为它们在缺乏 MPC 等私人且可信的承诺技术的情况下引入了新的共谋向量， FHE 和 TEE。
这篇文章大量借鉴了分布式系统文献，概述了一项在 mev-boost 拍卖中启用“锁定状态”能力的提案，并提供了对该“锁定状态”的可见性的后续功能。这种方法的最终结果是，区块建造者不再因建造区块其余部分的不确定性而有效地“管道停滞”，这为“协作区块建设”打开了大门。在分布式系统方面，我们正在利用可见性为以太坊分布式状态机创建一个“引导腿”去中心化多版本并发控制系统。
这种方法的主要优点是，它为在这些高速套利中竞争的搜索者保留了基本的隐私和出价更新能力，与以前的“车道”方法相比，支持更通用的套利，并且可以轻松部署到当前市场。主要缺点是它在区块顶部创建了单笔交易套利的“伪神殿”，并提供了新的审查和恶意攻击向量。由于该提案只是一个草图，因此关于如何有效地定价锁定状态的成本、对搜索者出价策略的影响以及如何将拍卖推广到锁定一组状态的能力，仍然存在很大的未知数。
国家锁定拍卖的理想房产
虽然并不详尽，但一些立即明显的有利特性：
- 锁柜安全- 在确认区块之前泄露锁定状态的人的地址会创建有针对性的 DoS 向量。
- 投标更新能力——提交状态锁的搜索者应该能够更新其事务的参数，只要它不修改状态访问列表。
- 锁定状态可见性- 锁定状态的存储槽应该对区块构建者公开可见。
- 保证锁定支付- 无论搜索者是否更新出价，支付交易都应包含在锁定状态的块中。
- 抢注阻力——确保锁定大量状态的成本过高，以防止恶意破坏。
- 争用意识- 缺乏的代价应该反映写入该状态的兴趣程度。
访问列表
在本文的大部分内容中，我们将要锁定的状态称为“访问列表”。在EIP-2930的上下文中，状态访问列表A A被定义为元组序列：
在哪里：
- \text{address}地址是与交易交互的合约或外部拥有账户（EOA）的以太坊地址。
- [\text{storageKey}_1, \text{storageKey}_2, \ldots] [ storageKey 1 , storageKey 2 , … ]表示交易将访问的指定合约存储中的存储密钥列表。
附录 A中显示了交换的访问列表示例。
提案：接力运行单锁拍卖
将搜索者表示为S S ，中继者表示为R R ，部分区块构建者表示为PB P B ，拍卖过程如下：
- 公开拍卖：
在进入时隙的截止时间T_{cutoff} T cutoff秒之前，搜索者通过两个不同的事务向R R提交其状态锁承诺：
\text{提交状态承诺}(n, A, tx_{状态}, tx_{付款}, b)SubmitStateCommitment ( n , A ,交易状态,交易支付, b ) _ _ _ _ _ _ _ _ _ _ _ _在哪里
- n n ：槽位号。
- A A ：访问列表。
- tx_{state} t x stat e ：状态访问事务。
- tx_{ payment} t x payment ：确保覆盖锁定成本的支付交易。
- b b : 出价，
提交后R R验证：
- b b必须满足或超过基于A A的锁定储备成本。
- 锁定储备成本由下式确定：
\text{锁定成本}(A) = C \times |A|锁定成本( A ) = C × |一个|在哪里：
- C C表示每个存储槽的固定成本， |A| |一个|是tx_{state} t x s t a t e的访问列表A A中存储槽的计数。这种方法天真地使锁定大量状态变得更加昂贵，但远非理想的定价规则。
- tx_{state} t x stat e应该是访问列表等于A A的事务。
- tx_{ payment} t x payment应该是从没有调用数据的 EOA 向验证器付款的交易。
- ( tx_{state} t x stat e , tx_ { payment} t x payment t )在区块顶部一起模拟，支付b b承诺的金额。
- 获奖者选择：
- 在T_{cutoff} T c u t o f处， RR选择最高出价：b_{max} = \max(\{b_i | b_i \geq \text{LockCost}(A_i), \forall i \in S\})b m a x = max ( { b i | b i ≥ LockCost ( A i ) , ∀ i ∈ S } )
- R R然后向调用以下命令的任何人公开与 b_{max} b m a x关联的获胜访问列表A_{ max} A m a x ：
- 投标更新和部分区块提交：
选择获胜者后可能会发生两项主要活动：
获胜的搜索者addr_{max} a d d r m a x可以通过以下方式更新其状态访问事务：
\text{UpdateStateCommitment}(n, addr_{max}, A_{max}, tx_{state\_new}, b_{new})UpdateStateCommitment ( n , a add r max , A max , t x state _new , b new ) _ _ _ _ _ _ _ _ _ _ _ _ _ _在哪里：
- n n必须等于与addr_{max} a d d r m a x中标出价相关的最新槽位
- R R必须验证更新后的状态访问事务tx_{state\_new} t x s t a t e _new具有等于A_ {max} A max的访问列表。
- 并且支付交易tx_{ payment } t x payment隐式保持不变。
部分块构建器查询GetLockedState(n) GetLockedState ( n )以获得A_ { max } A max ，根据此信息构建部分块，并使用以下命令提交它们：
\text{SubmitPartialPayload}(TX_{列表}, b_{PB})提交部分有效负载（ TX列表， bPB ） _ _ _在哪里：
- TX_{list} T X l i s t包含交易列表
- b_{PB} b P B表示部分块的出价。
当接收到部分有效负载提交时，中继器 ( RR )执行以下步骤：
- 1.交易组合： RR创建
\text{CollabBlock = }(tx_{状态}, tx_{付款},TX_{列表})CollabBlock = ( t x状态, t x付款, TX列表) _ _ _ _ _ _ _ _ _ _ _ _ _- 2. 区块验证： R R模拟CollabBlock C o l l a b B l o c k执行通常的区块验证，并确保组合区块出价等于b_{max} + b_{PB} b m a x + b PB 。
- 3. 支付处理： RR制作、签名并插入支付交易以支付验证者和部分区块构建者
- 4.状态根计算：如果验证成功， R R计算块的状态根和相关字段，以确保与最新的 EL 和 CL 规范兼容，插入具有最新负载属性的信标块，并可供
getHeader调用验证器。
以下是艺术家对上述拍卖过程的再现。
附录 B中提供了继电器规格变更的粗略草图。
分析
这种方法满足了我们状态锁定系统的大部分核心目标：确保Locker 安全、出价更新能力、锁定状态可见性和保证锁定支付，初步尝试抗抢占，并且不尝试争用感知。更进一步，锁定状态可见性通过允许构建者更自信地将部分块附加到块顶套利，为协作块构建奠定了基础。该设计故意避免在SubmitPartialPayload提交部分负载期间检查冲突事务，以避免阻塞任何其他也打算触及有争议锁定状态的事务。 BBlock 构建者可以自由发送有冲突的区块，但他们现在可以提前意识到冲突，这对当今的市场来说是一种进步，并创造了参与的动力。搜索者也被激励参与，因为这使得进入 stat arb 变得更容易，并增加了区块包含的可能性。中继会承担额外的工作，因此会产生额外的成本，但这种方法使通过迂回激励中中继之间的第二次价格拍卖获利的能力正常化。
一个值得关注的领域是转向更加以中继为中心的区块构建和标准化构建中继。我的偏见和谨慎的初步反应是，我们应该接受这一趋势，只要它不会就构建哪些区块产生意见，或者给一方带来不平等的优势。从这个 POV 来看，中继将继续容纳更多与拍卖相关的逻辑，作为构建者网络中值得信赖的第三方，每一个额外的逻辑都理想地有助于促进更多协作的区块构建。
这种方法不需要更改协议，并且可以与当前的 mev-boost 拍卖并行运行。此外，它创建了一种“通道”方法，而不将其限制为单一套利类型，但并未完全通用，因为它将块顶套利限制为单个交易。因此，探索捆绑支持是未来的理想探索，但如果天真地进行，可能会通过提交整个区块的新途径造成额外的复杂性。
然而，采用这种方法存在一些复杂性。一是它存在冷启动问题。如果在发布时只有一名搜索者具备了在此次拍卖中竞争的能力，那么他们很可能会在短时间内以非常便宜的价格占据主导地位，具体取决于锁定储备成本价格。其双重意义在于，只需要一名搜索者的参与就能让其余搜索者滚雪球。另一个需要改进的地方是，这种设计只关注单个继电器的情况，但实际上，有很多继电器都是独立工作的。一种想法是同步可能并不重要，因为投标取消是一个类似的无法保证的交叉中继问题。在多中继场景中，最好的情况是每个人都同意要锁定的状态。在最坏的情况下，每个都有不同的状态集和为所有潜在路径构建的部分块构建器。这会产生更多的工作，但至少它是可并行的，并且仍然比现状有了显着的改进。未来探索的另一个领域是，考虑到其更复杂的验证逻辑，这种方法如何与乐观中继一起发挥作用。
最后，这里最重要的未知因素是锁定定价机制和国家承诺对搜索者策略的影响。锁定定价机制非常不明确，而且很可能会出现滑稽的错误；因此，后续工作应尝试以分析性和对抗性的方式对此进行推理。将历史状态访问纳入定价机制也很困难，因为如果天真地完成，这将是一个非常大的更新向量，并且无法像基本费用所依赖的那样插入到区块中。弄清楚这一机制的进展也将有助于评估这次拍卖的审查向量有多大，并更具体地梳理出激励措施。还应该考虑为进行统计套利创建新的前期成本的影响，但在最坏的情况下，搜索者可以有效地取消他们的交易并简单地支付费用，而不需要他们承诺以他们想要的价格进行大量交易。不再根据其他领域的信号发现吸引力。
附加组件
- 可以使用随机的关闭时间来阻止最后一秒的投标。但在多个独立接力赛的情况下，这是以每个接力赛产生不同的获胜者为代价的。
- 国家锁定拍卖可以采用第二价格规则来确定付款，鼓励真实的投标。这可以通过将退款交易插入到区块中以获取差价来实现，成本为 21k 天然气。
- EIP-2930 事务类型可用于状态访问事务，但它们确实支持对非访问列表提供的存储槽的访问，因此不会启用盲目信任。总的来说，朝这个方向前进将有助于简化所有未来的协作建设工作。
- 中继中的块结构提供了插入无条件包含列表的理想时间。
- 保持竞价开放，以将状态访问交易替换为您自己的交易，只要它触及与原始状态相同的状态即可。与此相关的激励因素还不清楚。
- 允许并行对每个重叠访问列表进行拍卖。
- 这里的一个挑战是，代表对两个池进行套利的访问列表可以分为两次拍卖来对每个池进行套利，并且单独锁定每个池的成本可能不会像有人试图同时锁定两个池那样高。因此，概括需要某种形式的组合拍卖，允许您在赢得另一次拍卖时有条件地出价。
- 另一个挑战是，在单次拍卖的情况下，中继可以确保获胜的交易将产生特定的访问列表。在双重拍卖的情况下，我们不能再仅通过查看第一个交易的访问列表来确定第二个交易的访问列表。以第二笔交易为例，该交易以交易 1 中修改的余额为条件。虽然我们应该能够检测到这种读写冲突的可能性，但它很可能不够稳定，无法连续堆叠这些拍卖某个东西的上放。中继可以模拟第一次拍卖获胜者之上的第二笔交易，但这并没有给我们足够的时间来进行多次拍卖。最有可能的是，需要对事务写入和读取状态的能力施加一些限制来解决此问题。
ePBS 的可行性
将这种方法与未来的“ePBS”之类的方法集成的挑战是，我们需要将拍卖转移到证明者层，这天真地需要额外的同步期。网络必须就获胜访问列表“是什么”达成一致，更不用说这在协议层激励的 p2p 游戏了。
反对将此类内容移入协议的一个原因是，从验证者的角度来看，它不会影响网络上的资源，或多或少的锁不会影响执行验证者职责所需的资源需求。此外，锁定拍卖并不会对网络造成活跃风险。如果拍卖失败，那么我们就会回到当前的区块构建状态。支持将其转移到协议中的一个论点是，拍卖从协议的状态中产生收入。
结论
该提案勾勒出一种相对粗糙的机制设计，用于拍卖以太坊上的区块顶部状态锁，并实现区块构建器市场中的协作。虽然不是最终解决方案，但它为状态锁实验创建了一个理想的界面，并解锁了区块构建市场的新方面，这可能会帮助我们摆脱当前的局部最大值。假设有一个理想的锁定定价机制，这种方法可以迅速投入使用，并使我们朝着更好的建筑商市场结构迈出一步。
附录
A. 访问列表示例
访问列表示例
- tx 哈希 0x84ba67793c7aa0140ae9f7cbc58a7bec04099672d467dfe280ec5987b5f26b46将
Wrapped Ether交换为Porktoshi Nakamoto。
通过 创建 通过这些python 脚本创建。
[ { "address" : "0xa65303cbe1186f58dda9cf96b29e1e89ae90b165" , "storageKeys" : [ "0x0000000000000000000000000000000000000000000000000000000000000008" ] } , { "address" : "0xb39bc86ac75118011f646276fca48d56e54c4854" , "storageKeys" : [ "0x000000000000000000000000000000000000000000000000000000000000000d" , "0x7e3bb96fe9c3e8bf8baff39136a5e5778a1f21be90df3270983ce535ed884516" , "0x9db3014a7ecc5c8baca43505a03b4e7e24c2ec389a973d5605a299f04defc730" ] } , { "address" : "0xc02aaa39b223fe8d0a0e5c4f27ead9083c756cc2" , "storageKeys" : [ "0x377eec8667584e30e85471441b46e69393e5f35d2b63a0b4c26a5b1f6d059aa5" ] } ]这里
- 0xC02aaA...3C756Cc2是 WETH 代币合约
- 0xb39BC8...e54C4854是 PORKTOSHI 代币合约
- 0xA65303...AE90B165是 PORKTOSHI/WETH Uni V2 池
根据 PORKTOSHI 合约的存储密钥，我们可以看到存在一些非标准 ERC20 行为，源代码也验证了这一点，但这不是重点。
B. 继电器规格粗略变更
前面几节解释了验证规则和内部逻辑。
relay_SubmitStateCommitment
允许参与者提交特定时段的国家承诺。
接受：
-
n（槽位号）：表示槽位号的整数。 -
A（访问列表）：详细说明事务要与之交互的状态键（address和storageKeys）的对象数组。 -
statetx（签名交易）：签名交易的十六进制字符串。 -
paymenttx（签名交易）：签名交易的十六进制字符串。 -
b（投标价值）：代表投标价值的整数，以 wei 为单位。
-
返回：确认提交。
relay_GetLockedState
获取与指定槽位的中标相关联的访问列表。
接受：
-
n（时隙号）：表示请求访问列表的时隙号的整数。
-
返回：
- 访问列表 (
A)：详细说明指定槽最高出价的状态键（address和storageKeys）的对象数组。
- 访问列表 (
relay_SubmitPartialPayload
使部分区块构建者能够提交一组交易作为部分区块提案。
接受：
-
txList（交易列表）：表示交易的十六进制字符串数组。 -
b（部分区块的出价）：代表部分区块的以 wei 为单位的出价的整数。
-
返回：部分负载提交的确认。
