在不久的將來，App-Rollup、Micro-Rollup 或 RollApp 都將被稱為 App。
原文：Micro-Rollup ： A wave or just a shameless marketing term？（substack）
作者：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 本身的限制。
特定應用程式 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。
免責聲明：作為區塊鏈資訊平臺，本站所發佈文章僅代表作者及嘉賓個人觀點，與 Web3Caff 立場無關。 文章內的資訊僅供參考，均不構成任何投資建議及要約，並請您遵守所在國家或地區的相關法律法規。
