Raid - 基于排序的Rollup收件箱

感谢Nethermind和Taiko团队的讨论和反馈。 TL;DR Raid（"入口数据追溯证明"）是一组智能合约，rollup入口可以采用这些合约以实现兼容预确认的基于序列的方法。Raid通过多级链上过滤，确保只有由预确认者提交的数据块被rollup节点视为规范。这是在不依赖信标链预览或像EIP-7917这样修改L1的情况下完成的。 更多背景信息可以在此处找到。 问题 Rollup需要一个L1入口来发布数据块。 OP Stack使用随机的`batchInbox` EOA地址，通过验证所有数据块交易是否由专用的`batchSubmitter`签名来筛选规范数据块。对于基于序列的方法，需要一个动态的`batchSubmitter`地址，以在L1提议者之间轮换。 在Taiko中，任何人都可以无需许可地将数据块发布到`TaikoInbox`合约，这对基于序列的方法是足够的，但由于任何人都可以随时发布，预确认者无法对有争议的状态做出可信的承诺。任何发出L2执行预确认的预确认者，如果对手在发布前改变rollup状态，都guaranteed会违背其承诺。 需要一种方法，在预确认者的时段内授予其对rollup的写入锁。目前的想法是向入口合约公开信标链预览，并用它来过滤数据块提案。虽然EIP-7917未来会解决这个问题，但目前预览是信标状态的一个函数，因此无法直接通过EIP-4788信标块根的默克尔证明来证明。相反，可靠地在链上公开预览需要悲观地ZK证明信标链函数，或乐观地发布并通过欺诈证明进行削减。 提案 Raid使用当前工具解决这个问题，但有一个权衡：它不兼容实时结算，因此可以被视为在EIP-7917生效前的务实短期解决方案。 - Raid入口跟踪`unsafeHead`和`safeHead`，它们是数据块发布的引用 - 任何人都可以无需许可地发布到入口，并指定是否要替换或推进`unsafeHead` - 入口将首先确保合约调用者是满足所有前提条件的预确认者 - 入口将验证`validatorProof` - 针对EIP-4788信标块根的默克尔证明，证明上一个`unsafeHead`发布期间的L1提议者 - 如果合约调用者尝试替换，`validatorProof`证明`unsafeHead`的发送者未在其L1时段发布，则用自己的数据替换`unsafeHead` - 如果合约调用者尝试推进，`validatorProof`证明`unsafeHead`的发送者确实在其L1时段发布，则将`unsafeHead`提升为`safeHead`，并用自己的数据替换`unsafeHead` - Rollup节点在推导rollup状态时使用历史`safeHeads`

• blobProposer_1blobProposer1 是一个无效的预确认，因此发布 B_1B1 回滚
• blobProposer_2blobProposer2 是一个有效的预确认，发布 B_2B2，并且 replaceUnsafeHead = false
• 由于 replaceUnsafeHead 为 false，blobProposer_2blobProposer2 的 validatorProof 证明 publicationId_{B_0}publicationIdB0 确实是在 blobProposer_0blobProposer0 的槽位中提交的
• 假设 validatorProof 有效，publicationId_{B_0}publicationIdB0 被提升为 safeHead，publicationId_{B_2}publicationIdB2 成为新的 unsafeHead
• Rollup 节点接收到 NewSafeHead 事件并处理 B_0B0 以更新其本地 L2 状态

槽位 N+2

• blobProposer_3blobProposer3 是一个有效的预确认，发布 B_3B3，并且 replaceUnsafeHead = true
• 由于 replaceUnsafeHead 为 true，blobProposer_3blobProposer3 的 validatorProof 证明它不是 blobProposer_2blobProposer2 发布 B_2B2 时的槽位
• 假设 validatorProof 有效，publicationId_{B_2}publicationIdB2 被 publicationId_{B_3}publicationIdB3 替换为 unsafeHead
• 由于没有新的 safeHead，Rollup 节点不更新其状态

槽位 N+3

• blobProposer_4blobProposer4是一个有效的预确认者，发布了B_4B4，并且replaceUnsafeHead = false
• 由于replaceUnsafeHead为假，blobProposer_4blobProposer4的validatorProof证明publicationId_{B_3}publicationIdB3确实是在blobProposer_3blobProposer3的时段内提交的
• 假设validatorProof有效，publicationId_{B_3}publicationIdB3被提升为safeHead，而publicationId_{B_4}publicationIdB4成为新的unsafeHead
• Rollup节点接收到NewSafeHead事件并处理B_3B3以更新其本地L2状态

假设

• 由于每个发布要么替换要么提升先前的unsafeHead，为了给信标块根在链上可用留出时间，每个块只能添加一个发布
• 根据前面的假设，理性的L1提议者将确保只有他们的发布交易生效
• 发布必须至少每天进行一次，以确保连续的提议可以访问所需的信标块根（只有最后8091个可在链上访问）。