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個可在鏈上訪問）。