基於應用程式的道路

08-02

本文為機器翻譯

展示原文

如果你想傳播這篇文章，請隨意與此主題互動

關於基於 rollups 的討論和興奮很多。原因很簡單，基於 rollups 就是基於的。具體來說，它們允許應用程序堅持使用其底層（+ 保持同步性）——同時獲得通常為 rollups 和應用鏈保留的幾個超能力（同時獲得安全性）。這些是定製、MEV 內部化和專業化等。我們過去通常很少談論基於 rollups 的原因是，過去的實施思想通常集中在使提議者過載並將所有內容變成單一鏈上——這在這些超去中心化系統中是不可擴展的。此外，這些設置的用戶體驗（在沒有預先確認或軟保證的情況下）根本無法滿足應用程序的需求。

我們認為，目前圍繞基於彙總的教條已經變得更好。然而，重要的假設、假設和中心化問題仍然存在。下面，我們將簡單概述過去基於彙總的計劃如何工作、當前實現如何工作，以及最終理想的協議外實現將是什麼樣子（以及協議內的最終結果）。

過去，人們普遍認為基於 rollup 的實現方式要麼成本高昂，要麼給現有提議者帶來巨大壓力（並提供糟糕的用戶體驗），要麼依賴於以太坊普通參與者範圍之外的參與者和中間人。這是因為有很多討論專門圍繞讓 L1 驗證者也積極排序和執行基於 rollup 的交易（本質上將其變成一條鏈，儘管壓縮發生在鏈下）。其他想法集中在選擇加入/選擇退出，但在 MEV-Boost 之外，眾所周知，MEV-Boost 負責大多數構建的以太坊區塊 - 這使得協議外的主動集成更加難以管理和獲得關注。正如您稍後會看到的那樣，我們相信至少“高效”基於 rollup 的首次實現可能會在 MEV-Boost 的影響範圍內發生，因為它使集成和一致性變得更加容易。

在下面的任何示例和提及 rollup 時，請記住壓縮發生在鏈下（發佈到 L1 的數據以壓縮形式進行）。我們已經非常習慣於現有的 L2，它們的序列器處理這項工作（完整節點保持完整狀態）。在基於 rollup 的 rollup 中，壓縮工作是一個更大的問題，因為在下面的 Taiko 示例中，任何人都可以進行這種壓縮。在 MEV-Boost 示例中，這很可能由在基於 rollup 上運行完整節點的搜索者和構建者完成。這裡需要注意的一點是，與任何其他區塊鏈類似，運行完整節點的動機必須由基於 rollup 上的顯著牽引力來創造。rollup 上的活動量必須足夠大，以便有人進行壓縮工作，或者搜索者和構建者在那裡活躍起來。或者在初始引導階段，他們必須得到額外的激勵。

就迄今為止以太坊上基於 rollup 的實時實現而言，最明顯的例子是 Taiko，其功能與上面描述的有很大不同。它的運作方式也與更集成的（終局前）解決方案完全不同。我們在下面概述了 Taiko 的運作方式：

Taiko 採用單獨的 L2 內存池，搜索者參與即時 (JIT) 拍賣以構建最有價值的 L2 批次，類似於 L1 上的提議者-構建者分離 (PBS) 操作方式。這些搜索者競標讓他們的批次被 L1 區塊構建者收錄，後者選擇最有價值的批次。此模型可導致 L2 區塊構建者競相提取最大 MEV，與 L1 PBS 類似。

在此設置中，要獲得以太坊的同步性和可組合性，您需要領先的提議者和已知的前瞻性子委員會成為基於彙總方案的參與者。目前情況並非如此，理論上，區塊/交易只是被強行加入 - 這與當今彙總的中心化排序器非常相似。

最終實現基於 Rollup 的協議外實現，使其適合當前的區塊構建管道 (MEV-Boost sidecar)，並實現全面參與，這可能是實現大多數希望構建基於 Rollup 的應用程序開發人員所尋求的屬性的下一步。這些屬性通常是：

特性：

關於 MEV 保留/內部化方面，值得一提的是，在大多數提議的設置中，以太坊驗證者（納入權力）仍然擁有相當大的權力，因為他們最終決定什麼可以進入區塊（什麼不能）。因此，他們會希望得到一定數額的報酬。你幾乎可以將 rollup 想象成當前範式中的搜索者（因此，可以從拍賣中獲得一些價值）。

從以太坊（和其他單片鏈）的現狀可以清楚地看出，有大量應用程序渴望定製、專業化和 MEV 保留，同時實現以太坊安全性（和同步性）。我們之前已經在這裡和這裡的文章中深入介紹了模塊化設置的原因，以及我們最近在這裡和這裡做的關於應用程序開發人員為什麼要構建模塊化的兩場演講。

MEV-Boost 側邊車集成最終可能會看起來像這樣，請記住，這要求構建者與受支持的彙總集成（除非我們直接採用 MEV-Boost 中繼式設置，儘管這會失去上述許多權力）。構建者最終可能會成為越來越強大的實體，我們稍後會討論這一點。提議者也必須選擇加入（就像他們目前對 MEV-Boost 所做的那樣），儘管如果運行這種基於彙總的側邊車的提議者的利潤更高，那麼其他人也可能會參與（因為大多數追求利潤）。

請記住，L2 票證拍賣可能會提前完成（就哪個 L1 提議者應該包含哪個 L2 區塊而言）。這是因為基於彙總的網關協議需要確保提議者已選擇加入基於彙總的方案。網關會知道這一點，因為我們還可以預測當前/即將到來的驗證者小組委員會中的未來提議者（並且可以看到誰選擇了加入）

目前已經出現了一些關於如何在以太坊上實現這一實現的提案（既包括預先確認層面，也包括基於彙總的適用方式）：

對於基於彙總：

對於預先確認：

然而，目前還沒有明確的觀點表明這將如何全面實施（如所有 MEV-Boost 驗證者和構建者都參與其中），但很明顯這些事情即將到來，而且它們將首先出現在核心協議之外。

以太坊核心社區內部也明顯希望更好地支持基於彙總。這裡我們特別指的是希望單槽最終性，但同時也希望更快的出塊時間——這更適合基於彙總。與以太坊上的大多數升級一樣，這些事情還很遙遠。另一方面，預確認/提議者承諾已經在主網和測試網上投入生產——儘管他們受到了社區成員的強烈反對（再次強調，集中化問題——我們將在後面進一步討論這些問題）。

還有一些其他有趣的想法（提供預確認），它們利用在單個 MEV-Boost 拍賣中構建部分區塊，方法是在通常的拍賣時間範圍內運行多個拍賣。在Linoscope （Nethermind）的基於多輪 MEV-Boost 的預確認中，其想法是，在 MEV-Boost 拍賣中，您有固定數量的更快輪次，您可以在其中構建（並簽署）部分有效載荷（區塊），此簽名（來自提議者）充當預確認。然後，完整區塊（帶有部分有效載荷）在正常時段結束時正常傳播。上面的XGA也使用了類似的想法。但是，他們沒有將一個拍賣分成多個拍賣，而是將區塊空間分成兩個通道 - 優先和非優先。這樣做是為了提供出售未來洩漏較少的區塊空間的能力（而無需啟用太多 MEV） - 這意味著驗證者將出售對非優先區塊空間的訪問權限（用於預確認）。

請記住，為了簡單起見，削減、註冊和定價等內容被排除在外

如上圖所示，預確認協議可能類似於 Spire團隊在其預確認網關中提出的協議；請參閱此處。通過以太坊提議者前瞻，可以提前知道提議者/預協商者（可能已委託排序者角色）。如果前瞻中沒有活躍的 Sidecar 參與者，則基於 Rollup 可能會使用回退機制來選舉排序者。回退機制的其他用例（ h/t mteam ）也可能是如果預協商 Sidecar 中的參與者已被削減（或沒有抵押品）

雖然以上大部分內容都集中在以太坊的複雜性及其為 based rollup 提供平臺的道路上，但也有其他網絡可以支持它們。下面，我們將介紹一些可以構建 based rollup 的地方以及專門為支持它們而構建的網絡。

就能夠支持（並且是為了支持基於 rollups 而構建的）網絡而言，有相當多的網絡。這裡特別值得注意的是共享排序器，它本質上是用於對（基於）rollups 進行排序的網絡：

共享序列器
- 阿斯特里亞
- 濃咖啡
- 半徑
- 節點套件
數據可用性層（帶共識）
- 塞拉斯蒂亞
- 可用性
快速整體式
- Solana（大型生態系統 + 允許高效彙總的屬性）

總而言之，基於彙總的內容包括：

一種鏈下狀態機，將其區塊的排序委託給底層（及其提議者）。排序者通常是拍賣或領導者選舉的獲勝者（例如以太坊的子委員會及其後續席位）。在大多數情況下（為了避免過載），該排序者可能是負責納入的提議者（這是底層集合的一部分）；同時它將 rollup 區塊的執行、約束和構建委託/外包給更復雜的參與者（構建者）——ala MEV-Boost。

要求和屬性

既然我們已經介紹了基於彙總的內容，那麼值得花些時間介紹一下如何操作。現在推出基於彙總顯然沒有錯，但必須對基礎層進行相當多的更改，才能真正支持它們，使它們與非基於彙總相媲美。

顯然，將 rollup 建立在更適合自己的鏈上（例如出塊時間更快的鏈）是非常有意義的。但是，由於我們顯然有興趣利用以太坊的去中心化、審查阻力和用戶以及流動性，因此這裡需要進行相當多的改變。

雖然基於 rollups 在 Solana 上也非常有意義，因為有更快/連續的 slot，但需要對同步函數進行更改（即 sidecar），以處理同步可組合性。這裡與 Jito 的一些交互（例如 MEV-Boost）對於拍賣和委託來說可能也很有意義。

我們已經提到了上面的一些要求，但讓我們（盡我們所能）涵蓋所有我們認為基於以太坊、Solana 和 Celestia 的彙總的關鍵要求。

對於以太坊來說，要求（為了獲得適當的用戶體驗和獲得上面概述的屬性）：

對於 Solana 來說，該鏈實際上非常適合基於支持的彙總。它具有“快速”（在這種情況下是連續的）出塊時間，這提供了快速的確定性共識（在沒有預先確認的情況下，基於彙總的彙總所需的屬性）。但是，這裡仍然存在一些問題，例如：

順便提一下，我們已經看到類似基礎結構（ZK Compression）在 Solana 上上市，同時人們對在 Solana 上啟用/構建彙總的項目重新產生了興趣並獲得了資金支持。ZK Compression 在某些方面與基於 ZK-validium 的工作原理非常相似。這通常是因為，儘管 Solana 顯然是一種極其高效的單一狀態機，但它變得相當臃腫——而且應用程序沒有自定義控制，也沒有 mev 內部化。

對於 Celestia 來說，實際上有很多屬性非常適合基於彙總。輕客戶端的可驗證性、充足的區塊空間和提供共識的“惰性”基礎層。有一些變化會使其更適合基於彙總：

按順序還是不按順序

如上所述，有相當多的方法可以實現基於排序的本地（或協議外）同步。這個範圍在當前（和更早）的討論中非常相關，因為它非常符合“不要使以太坊共識超載”和 homestaker 的優雅。許多允許執行和排序保證（來自整個或小組委員會）的驗證者的實現將極大地超載以太坊共識。因此，我們發現有必要更多地討論這個主題：

答應我，我只是需要確認

此外，正如我們所見，至少在加速區塊之前，需要進行預先確認。關於如何實施這一點仍存在很多爭論，但這肯定值得考慮。作為回顧，預先確認是由提議者或委託參與者提供的關於未來納入或執行的承諾，他們有能力在指定時間鎖定或提供對狀態的訪問。在基於 rollup 的網絡中，這很重要，因為提議者可以保證 rollup 區塊最終會被執行/納入。顯然，在這種方案中，可能會對參與者施加大量削減保證金，以確保承諾得到履行。這是協議內的理想世界，因為協議外會恢復為由一小部分人而不是整個協議的社會共識進行的社會削減。

包容性保障
- 委託執行、區塊構建和排序
- 保證區塊/交易將被包含在一個區塊中（但不保證它們將被執行客戶端執行）或按特定的順序排列
- 無法確保應用程序之間的可組合性
- 更容易定價
- 外包排序器（構建者）和提議者的合作（中繼可能發揮通常的作用，儘管這裡的壓力也可能很大）
執行保證
- 實時有效性證明或抵押。
- 給提議者帶來沉重壓力
- 定價更難
- 重要的是，我們認為基於 rollups 可能會同步觸及以太坊 L1 狀態 - 其中應用程序的可組合性需要執行保證

雖然目前預確認的使用非常有限，但其應用範圍非常廣泛，可以為提議者承諾提供相當靈活的基礎層。提議者承諾的當前屬性（預確認/承諾邊車之外）僅限於區塊構建時的狀態確認（即每 12 秒一次）。但是，已經有一些協議外的承諾方案（例如 Chainbound），可以使提議者向其他人發出有關其特定區塊的承諾，同時支持包含預確認中的基於密鑰的彙總屬性。如上所述，這是我們非常渴望擁有的。如果您對協議外的預確認感興趣，我們強烈推薦Chainbound 團隊的這次演講。

除了更快的區塊速度以實現更好的用戶體驗之外，預確認還能帶來其他關鍵點（除了用於基於彙總之外）。例如：

提議者承諾、票證和證明者

提議者承諾的最終目標非常廣泛，總體思路是他們將能夠支持更多的用例，例如：

在協議內承諾和區塊提案權方面，有幾項提案和實施方案正在討論中，例如協議強制提案人承諾 (PEPC)和執行票證 (ET) (+證明者-提案人分離 (APS) )。ET 受到廣泛關注，因為它們將允許在協議內市場 (抽籤) 購買區塊提案權。APS 的想法是將 L1 驗證者角色分為兩個獨立的角色 - 執行者和信標 (共識) 提案者。前者的任務是提議區塊有效載荷 (這方面的構建很可能外包給建設者，或者我們讓建設者來扮演這個角色)。後者 (信標或證明者) 的任務是投票確定區塊有效性規則 (對於基於彙總的區塊尤其重要，因為可能會概述更多規則) 並通過包含列表限制執行權。這很可能（尤其是在超級建造者和圍繞預確認和基於彙總的集中化問題的世界中）提供更高的審查抵抗力。如果您對預確認歷史感興趣（請查看此處）。

它們越來越大

超級建築師

您可能已經注意到，為了避免超負荷或確保更好的市場效率，很多工作被委託和外包給更專業的參與者。這意味著，以太坊上已經發生了一段時間了，而它導致的結果就是，將大部分繁重的工作交給建設者（高度複雜的實體）。這導致了所謂的“超級建設者”的出現。MEV-Boost 管道中的當前建設者群體可能也將在協議內部（和外部）發揮關鍵作用，以進行基於彙總、預確認和承諾。

原因很明顯，我們不想讓以太坊的共識超載。我們無法要求每個提議者都如此專業，他們也沒有能力做到。這是普遍的市場力量，但它確實會導致集中化，並帶來許多風險。這在今天已經生效，目前有 3 個構建者構建了絕大多數以太坊區塊（其中兩個，Titan 和 Beaverbuild，構建了近 80%！）。今天的提議者也與中繼者有著極其信任的關係（希望隨著 ePBS 的進步，這種關係會有所減弱，儘管目前還不清楚）

出於排序、執行保證和區塊構建的原因，構建者（在基於彙總的情況下）可能會在彙總上運行完整節點。同時，他們需要能夠（在預協商的情況下）正確定價這些區塊/捆綁包（一些構建者可能會將這種預協商定價外包給搜索者）。納入保證預確認的定價要容易得多，而執行保證則需要相當複雜的技術，這仍然是一個懸而未決的問題。

關於基於 rollups 的話題，超級建造者通常可以被認為是一個專門的參與者，他不是為單個鏈（以太坊）建造，而是為一組鏈（以太坊+Rollups）建造。這是必要的，特別是如果我們想要塊內同步性和跨域 rollup 互操作性。在某種程度上，你也可以將 Optimism 的超級鏈排序器/建造者視為 OP-Stack 鏈的超級建造者。以及 Astria/Espresso 的去中心化排序器網絡（但如果沒有單一領導者，則更多是多併發）。委託給建造者的一個有趣方面是，多個 rollups 的票證持有者可以為這些域之間的同步可組合性提供包含保證。

超級建設者這個術語還可用於指他們在原有職責（構建模塊！）之外可能從事的課外活動，例如承諾和預先確認。

在所有這些情況下，我們可能需要為建造者提供大量債券（權益），尤其是委託給他們的工作越來越多的情況下。最好是，外包給他們的許多功能也應該在鏈上（協議內）可證明，以確保公平、穩健和正確的削減。這標誌著建造者方面的橫向擴展增加（Justin Drake 隨口說他們對此沒意見？）。這裡有很多令人擔憂的地方，比如多塊 MEV，建造者建造的彙總數量遠遠超過其他所有人（或更擅長提取 MEV），以及可能持續出價高於所有其他建造者。與所有事情一樣，這種進一步的複雜化和優化也將導致進一步的中心化和新參與者的更高進入門檻（除非他們是 Citadel）。有一件事似乎很清楚，那就是在建造者擁有更多權力的世界中，至少迫切需要包含列表 (IL)。

除此之外，流量正越來越多地轉移到鏈下/私人訂單流。擁有獨家供應商（以及集成供應商）的構建者比沒有的構建者做得好得多，而這少數人也有可能從任何基於彙總的集成中獲利最多。在某些應用程序（或 Telegram 機器人）可能擁有彙總並且還擁有流向構建者的獨家流量的情況下，這也可能令人擔憂。Burak Öz 、 Danning Sui 、 Thomas Thiery 、 Florian Matthes在他們最近的論文《誰贏得了以太坊區塊構建拍賣以及原因？》中很好地強調了這些問題，尤其是圍繞上面提出的高進入門檻問題。

有趣的是，對於這種給建造者增加的工作量，在利潤分配方面，他們（至少在鏈上）獲得的利潤最少。儘管由於三個主要建造者中的兩個也是道具店，搜索者的利潤顯然也大部分屬於他們。即使是非交易建造者也可能與搜索者達成收入分成協議，因為他們不在搜索者的流量上進行交易。目前，正如Yuki （Sorella/Fenbushi）所指出的那樣，MEV 與非 MEV 的利潤大致平均分配，有大量利潤留給了應用程序，而這些應用程序往往最終落入提議者的手中。

它確實非常清楚地表明瞭一件事，那就是允許/能夠捕獲（即內部化）自己/他人的 MEV 的應用程序（或項目）擁有巨大的機會。顯然，在當今時代，隨著鏈上經濟活動的數量增加，這很可能意味著他們可以勝過那些無法做到這一點的人。這些剩餘的利潤空間是協議的機會，這些協議可以讓應用程序變得更好、更高效。

應用程序如何在基於彙總的基礎上構建其應用程序？

如前所述，將應用程序構建為基於 Rollup 的原因有很多，特別是如果您已經在底層紮根並部署。讓我們舉一個例子，說明應用程序如何作為基於 Rollup 啟動，同時保留其在 L1 上的現有合約。

對於 Uniswap 來說，你可以讓Uniswap Router運行在基於 rollup 中，並讓應用程序通過 rollup 進行調用（這意味著 Uniswap 有望通過拍賣將部分流經它們的流量內部化）。例如，想要接觸 L1 Uniswap 流動性的意圖協議必須通過基於 rollup 上的路由器進行調用。

這可能還會與同步性一起發揮作用，以便基於 rollup 操作創建可在 L1 上執行的函數。這將很有趣，因為應用程序可以訪問（至少讀取）以太坊，並且將來可能調用其智能合約。這是 Uniswap 尤其想要的，因為許多應用程序在每個區塊都會調用其路由器/合約（想想大多數意圖協議和許多其他協議）。Aave、Maker 等也是如此。

在 Uniswap（以及所有其他希望內部化其 MEV 收入的應用程序）如何選擇排序器的情況下，它很可能是願意為排序區塊付費的排序器——這意味著嚮應用程序返回一些價值。在只有少數此類參與者的世界中，它達到可能返回價值的確切總額的可能性非常低，除非所有參與者之間具有完全的信息對稱性，並且能夠全部出價到上限（儘管此時你會預計會開始發生一些勾結）。

未來研究和總結

整篇文章可能都很清楚，關於這一切將如何結束以及它將如何影響我們今天使用的協議的某些方面，有很多重要的假設。時間表也不清楚，尤其是當它與協議中的事情有關時。
然而，很明顯的是，在非常完善的單片鏈上存在著龐大的應用程序生態系統，它們渴望擁有可定製、內化和獲得安全性的能力，同時又具有可組合性。
針對特定應用的順序不可知排序（即參見我們的排序文章）——不僅僅是 MEV 內部化，還有可驗證的排序規則、頻繁的批量拍賣、公平排序等。
Rollup 特定的分叉選擇規則（例如，僅當預言機定價更新時才有效的區塊）
最佳區塊有效性（超出最高費用）可以是相當任意的（例如不同於 => 最大化值）
區塊構建器的複雜性和水平擴展需要圍繞危險 (+ 多區塊 mev、區塊出價) 進行更多的研究；這將如何隨著操作碼/gas 限制/VM/分叉選擇規則的專業化而改變。
部分區塊構建 + 多併發提議者
使用協議內和協議外包含列表來約束塊構建器
如果委託給非綜合建造者，則定價（委託給搜索者？）
訂單流的彙總付款
連續區塊構建（ Solana 上的 ala Shreds ）
時間遊戲和效果（+證明人錯誤投票）

如果您的應用程序目前運行在單片單鏈上，並且您有興趣探索如何開始利用模塊化的各個方面（正如我們在過去一年中多次提到過的那樣），同時保持可組合性並與底層保持一致，請隨時與我們聯繫。

進一步閱讀：

感謝 Mathijs van Esch (Maven11) 和 mteam (Spire) 的審閱。