一文读懂基于软确认的排序方式
“我们希望确保非审查是区块提案创建的主要策略。”
原文来源：github
原文标题：BasedSequencingwithSoftConfirmations#408
原文作者：preston-evans98
编译：Yvonne，MarsBit
背景介绍
目前，模块系统正在进行工作，以实现“基于排序”的功能。这对于抵抗审查很有好处，但它牺牲了排序器提供几乎即时的软确认的能力。由于没有排序器对全局状态进行“锁定”，它们无法保证没有其他交易进来并改变它们所依赖的状态。
例如，假设Alice想在Uniswap上进行一笔交易，将1$ETH换成1000$DAI，滑点为1%。因此，她签署了一笔交易，并将其发送给排序者Steve，继而Steve给了一个软确认，确认交易将通过。大约在同一时间，Bob向另一个排序者Tom发送了一笔交易，Tom将1000$ETH换成了$DAI，使价格上涨30%。现在，如果Tom的区块在Steve的区块之前落位于DA层，那么Alice的软确认就会无效。
为了提供有竞争力的用户体验，我们非常想弥补这一缺陷。
初步构想：基于“首选排序器”的排序
对于该问题，一个天真的想法是嵌入中心化的排序器，并保证它们总是在每个数据处理层槽中获得第一执行权。因此，不是完全按照它们在DA层上出现的顺序处理blob，而是rollup总是处理来自首选排序器的blob，就好像它出现在其槽中的第一个索引一样。
不幸的是，这种方法很容易受到审查。具体来说，假设在DA插槽100末尾，在Uniswapv2与v3上的ETH价格之间存在巨大的套利机会。默认情况下，首选排序器将提取此套利，因为它们的blob将被处理，就好像它们出现在第101个时间槽的开头一样。但是一个聪明的数据处理层区块提议者会想要为自己提取套利。因此，他们会希望创建自己的blob来提取套利机会，并审查首选排序器，以防止他们的blob被处理。
进一步智能化：模拟多个提议者
关于【一文读懂基于软确认的排序方式】的延伸阅读
长推：复盘精彩刺激的 $RCH 大战
昨晚，$RCH与BTW进行了精彩的大战，项目方上线了产品并给LP添加了700ETH，但被聪明钱抢跑。随后，神盘出现，币价从0.2上涨到1u。项目方背景强大，有大机构背书，链上交易活跃。Sofa.org推出了两个产品，Earn和Surge，用户可以利用期权策略进行理财和预测未来走势。产品实力强大，能力超过web3团队。
长推：$RCH 能不能到20亿？无预留、无权限、燃烧通缩、上所才是起点
$RCH是新兴项目，初始加入池子的ETH价值300万，现市值7000万。若跌回1块，市值为2000万，上限无法预测。项目方烧了750ETH，加其他支出，合计400万。预计市值达15M，产品和资方有潜力，交易量高，无VC抛压和项目方币。预计上市后，市值5亿-40亿。
为了消除审查的动机，我们需要确保如果DA层区块提议者审查了首选排序器，他们的交易就无法处理。一种可能的方法是回归中心化排序，但这是不可取的，因为有审查的风险。一种更聪明的方法是要求多个DA层区块提议者合谋以有效地实施审查，同时鼓励每个提议者脱离cartel（模型）。换句话说，我们希望确保非审查是区块提案创建的主要策略。
要做到这一点，我们需要更改rollup状态转换规则。之前，我们提议的规则是这样的：
我们可以修改该规则，将来自非首选排序器的blob的执行延迟更长时间。我们可以在我们的证明输出中保存它们(或者实际上是对它们的承诺)，而不是在当前插槽中处理来自其他排序器的blob，并将它们作为下一个插槽的一部分进行处理:
这样，即使当前区块提议者审查了首选排序器并将自己的套利交易插入到数据处理层，他的交易直到下一个插槽结束时才会被处理。由于下一个数据处理层提议者不会通过审查首选排序器获得任何收益，我们可以预期排序器的bundle将落在该插槽中并提取套利机会。
我们可以通过将blob执行推迟更长的时间来进一步实现这一想法。我们可以将“based”blob的处理从下一个插槽延迟到未来3或5个区块。这样，为了获取自己的套利机会，必须串通起来的排序者越多，他们这样做的动机就越少。
免责声明：本文仅代表作者个人观点，不代表链观CHAINLOOK立场，不承担法律责任。文章及观点也不构成投资意见。请用户理性看待市场风险，以及遵守所在国家和地区的相关法律法规。
图文来源：MarsBit，如有侵权请联系删除。转载或引用请注明文章出处！
