撰文：KAUTUK，Stackr 开發者  編譯：Luffy，Foresight News

用諸如「什么是 Rollup」或「爲什么我們需要 Rollup」之類的話題來开始一篇 Rollup 文章，就像在蜘蛛俠和蝙蝠俠電影的每次迭代中殺死 Uncle Ben 或射殺韋恩媽媽和爸爸一樣。如果你正在閱讀本文，我假設你上述問題已經有了基本的了解，在此，我們跳過應用程序鏈與應用程序 Rollup 的爭論，直入主題。

特定應用程序 Rollup 的興起通用 Rollup 令人沮喪

通用 Rollup 就像印度的學校系統（我確信它們與其他學校系統具有相似的特徵，但我只對它有第一手經驗）。

運動員、歌手、數學家、思想家和經濟學家都需要經歷相同的過程才能獲得及格分數。這個系統並不「偏向」特定群體，但也不是對所有人都「公平」。但是嘿，我們交朋友了！（這稍後會很重要）。

同樣，對於通用 Rollup 上的應用程序，瓶頸是運行環境本身，因爲 Rollup 無法單獨滿足每個應用程序的需求。每個應用程序可能需要不同類型的優化，任何定制化改進對他們而言都是不合理的。但是，如果你只是進行嘗試並想要大致了解一些東西，那么這是最方便的選擇。此外，對於像一些普通學生一樣的某些應用程序，這可能是正確的解決方案！

特定應用程序 Rollup 令人困惑

好吧，我的孩子運動能力太強，不適合在公立學校上學，他需要特殊訓練。我需要送他去體校還是應該聘請私人教練……

Rollup 難以明確分類來玩個遊戲

下面有 8 個特定應用程序 Rollup。然而，每組中有 1 個項目並不真正屬於該組。你能看出是哪一個嗎？

應用程序專用性正在成爲一個令人費解的術語。有一些特定應用程序 Rollup，允許在其自身之上部署合約；也有一些特定應用程序 Rollup，可以允許合約部署，因爲它們的虛擬機支持它，但是會有一定限制；還有一些特定應用程序 Rollup，它們具有封閉的虛擬機或根本沒有虛擬機，並且不支持其他類型的开發。

將它們分類在一起公平嗎？

上述練習的答案：

Group1：Celo 是一個奇怪的選項，因爲它允許其他开發人員構建應用程序，而其他开發人員可以直接使用應用程序。第 1 組中可以考慮的其他項目還有 Fuel-v1、Aevo、RhinoFi 等

第 2 組：Loopring 是個奇怪的選項，因爲它是唯一專門構建的可直接使用的 Rollup，而其余的都是針對隱私、NFT 和 TPS 等特定功能進行優化的網絡，以便部署在其上的應用程序可以繼承這些功能。第 2 組中可以考慮的其他項目還有 Kinto、Kroma、Public Goods Network 等

在修改後的通用虛擬機中部署合約的問題

你部署智能合約的這些虛擬機只不過是圖靈完整的狀態機。你在它們上部署的合約只是對狀態本身的修改，它並不真正影響 VM 的核心狀態轉換規則。Rollup 本質上是虛擬機，你的業務邏輯位於其之上。

你的業務邏輯與 Rollup 的狀態轉換函數是分开的。

我也將其稱爲「構建應用程序的智能合約範例」，因爲你在虛擬機之上部署一些額外的邏輯。Rollup 並不「直接」關心證明應用程序的邏輯。VM 是 Rollup，而不是你的應用程序。

當然，你是虛擬機的唯一所有者，你的應用程序是唯一的公民，你可以不斷增強基礎本身以使其適合應用程序。你可以繼續增強狀態轉換功能 (STF)，添加 / 刪除操作碼來提高應用程序的性能，但應用程序仍然是獨立的並受到 VM 本身的限制。

就像蘭博基尼 Urus 拉着蘭博基尼 Huracan

特定應用程序 Rollup 上的單獨應用程序可以做得更好。如果你不斷增強 STF，使 STF 的範圍不斷變得越來越小以適應你的應用程序的業務邏輯，會怎么樣？最終，隨着你不斷增強，STF 將收斂到業務邏輯和 STF 重疊的點，此時你會意識到……哦，等一下！

Micro-Rollup 誕生

因此，Micro-Rollup 只不過是應用程序的狀態轉換函數是業務邏輯本身的 Rollup。

應用程序成爲 Rollup，可以在任何執行環境中以任何可能的方式管理狀態，並且狀態轉換規則可以直接應用在應用程序的運行時中。該應用程序可以不受任何限制地進行定制。證明與你的業務邏輯相關，而不是與機器相關，它使你的應用程序變得輕量級。

Micro-Rollup 在开發人員體驗方面不受限制。你可以使用任何你喜歡的工具來構建它們，因爲它們不受虛擬機限制。它們看起來像 web2 後端應用程序，但它們會定期向 L1 發布交易證明。我認爲這將成爲影響 web2 开發人員轉向 web3 領域的一個主要因素。

實際上，更好的例子是 Rimac Nevera，因爲它速度更快，而且是電動的，所以運行起來可能更便宜

這種方法的唯一缺點是針對每個不同應用程序的自定義證明機制。如果應用程序邏輯可以編譯成公共中介，那么證明公共中介就可以消除單獨證明每個應用程序的痛苦，但我個人認爲這只是效率和更快的开發之間的權衡。

有一些方法可以解決這個問題，而無需使用涉及虛擬機的執行層。如果有一個工具可以讓开發人員做到這一點呢？

這就是 Stackr Labs 的使命：我們正在構建一個 Micro-Rollup 框架和 SDK，以便任何人和每個人都可以不受限制地以他們想要的任何語言構建他們的應用程序，就像構建 web2 後端應用程序一樣。讓 Micro-Rollup 开發像編寫和部署智能合約一樣簡單，更不用說模塊化增加了开發人員選擇任何生態系統的能力。

那么 Micro-Rollup 是真的嗎？

一直都是，就像 Rollup 本身一樣真實。

像 Loopring、dYdX 和 Fuel-v1 等應用程序已經出現或已經存在很長時間了。這些是高度優化的 Rollup，具有專門運行的自定義邏輯來服務其用例。我所知道並親自參與過的第一個不基於虛擬機的特定應用程序 Rollup 是 Hubble Optimistic Rollup ，這個已有 3 年歷史的項目曾一度充當 Worldcoin 代幣的核心基礎設施。

現在區分這些術語變得越來越重要。

Micro-Rollups 的用例是無限的：

• 遊戲、交易所、NFT 市場等消費產品

• 應用程序鏈可以轉換爲應用程序 Rollup

• 你甚至可以構建支持獨特用例的新型虛擬機，從而打开虛擬機創新之門

結論

我之前展示的結構樹中缺少自定義狀態機的元素。

此外，對於單獨的應用程序來說，使用基於 VM 或 EVM 的 Rollup 來部署單個協議的效率並不高。它適用於已經擁有大量智能合約並在類似 EVM 的鏈上運行其協議的應用程序，但不適用於「想要更多的應用程序」並希望擺脫 VM 限制。

所以如果我們修剪這棵樹，最終的樹會看起來像這樣。這也是爲什么我認爲在不久的將來 App-Rollup、Micro-Rollup 或 RollApp 將被稱爲 App 的原因。

因此，Micro Rollup = App on Rollup App as Rollup。

鄭重聲明：本文版權歸原作者所有，轉載文章僅為傳播信息之目的，不構成任何投資建議，如有侵權行為，請第一時間聯絡我們修改或刪除，多謝。