撰文：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 的原因。
