作者：KAUTUK；來源：Substack；編譯：Kate, Marsbit

我的一條推文最近火了，在Web3在线社區中獲得了很大的關注！這是一個非常簡短的，由四部分組成的“推特”帖子，但我聽到你問，它到底是什么意思？讓我來解釋一下。

去他的Rollup，繞過陳詞濫調

用諸如“什么是Rollup”或“我們爲什么需要Rollup”之類的話題來打开一篇Rollup文章，就像在蜘蛛俠和蝙蝠俠電影的每一次迭代中殺死本叔叔或射殺韋恩爸爸媽媽一樣。如果你正在閱讀本文，你可能已經熟悉這些有據可查的論點。此外，如果你正在閱讀這篇文章，我認爲我們可以超越應用鏈與應用Rollup的爭論。那么讓我們切入正題吧。

特定於應用的Rollup的興起

通用Rollup令人沮喪

通用Rollup就像印度的學校系統（我相信它們也和其他學校系統有相似的特點，但這是我有親身經歷的）。

運動員、歌手、數學家、思想家、經濟學家和講故事的人都需要經歷同樣的過程才能獲得及格分數。從技術上講，這個系統並沒有“偏向”某個特定群體，但也不是對任何人都“公平”。但是嘿，我們交朋友了！(這稍後會很重要)。

同樣，對於通用Rollup上的應用程序，瓶頸是環境本身，因爲它不能單獨滿足每個應用程序的需求。每個應用程序可能需要不同類型的優化，但對他們來說，期望任何量身定制的東西都是不合理的。然而，如果你只是想嘗試一下，想要大致了解一下，這是最方便的選擇。另外，對於一些應用程序，就像一些普通學生一樣，這可能是正確的解決方案！

朋友呢？它是與你的應用程序一起構建的應用程序生態系統。如果你是一名企業家，你可以簡單地打電話給你的會計師朋友，讓他幫你向政府隱瞞稅款：)

特定於應用程序的Rollup是令人困惑的

好吧，我的孩子運動能力太強了，上不了公立學校，她需要特殊訓練。我需要送她去體校還是我應該僱一個私人教練.....

特定的復雜度

我們來玩個遊戲吧。

下面是8個特定於應用程序的Rollup列表。然而，在每個小組中都有一個不屬於該組的項目。你能認出是哪一個嗎？

應用程序特異性（Application-specificity）正在成爲一個令人費解的術語。有一些特定於應用的rollup允許在自身之上部署合約，也有一些特定於應用的rollup允許合約部署，因爲它們的虛擬機（VM）支持它，但它們的所有者限制它。還有一些特定於應用程序的rollup具有封閉的VM或根本沒有VM，並且不支持其他類型的开發。

把它們歸爲一類公平嗎？

上一題的答案~

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

第2組：Loopring是很奇怪的一個，因爲它是唯一專門構建的可直接使用的Rollup，而其他的是針對隱私、NFT和TPS等特定功能進行優化的網絡，這樣部署在它們上面的應用程序就可以繼承這些功能。其他可列入第二組的項目， Kinto, Kroma，公共物品網絡等。

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

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

你的業務邏輯與rollup的狀態轉換功能是分开的。

我也將其稱爲“構建應用程序的智能合約範式”，因爲你在VM之上部署了一些額外的邏輯。rollup並不“直接”關心如何證明應用程序的邏輯。VM是rollup，而不是你的應用程序。

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

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

在特定於應用的Rollup上的單獨應用程序可以做得更好！好多了！

如果不斷增強STF，使STF的範圍變得越來越小，以適應應用程序的業務邏輯，該怎么辦？最終，隨着你不斷增強，STF將收斂到業務邏輯和STF重疊的點，此時你將意識到……哦，該死，等一下！

Micro-Rollups誕生！

因此，Micro-Rollup只不過是一個rollup，其中應用程序的狀態轉換功能就是業務邏輯本身。

應用程序變成了rollup，狀態可以在任何執行環境中以任何可能的方式進行管理，狀態轉換規則可以直接應用於應用程序的運行時。應用程序可以自定義，沒有任何限制。這些證明與你的業務邏輯有關，而與機器無關。它使你的應用程序變得輕量級。

這些特殊的狀態轉功能數需要另一篇文章，敬請關注：）

就开發人員的經驗而言，Micro-Rollup是不受限制的。你可以使用你喜歡的任何工具來構建它們，因爲它們不受VM限制。它們看起來像web2後端應用程序，但它們會定期向父級L1發送交易證明。我認爲這將是影響web2开發人員向web3領域轉移的主要因素。

事實上，一個更好的例子是Rimac Nevera，因爲它速度更快，而且是電動的，所以運行起來可能更便宜，但我找不到一張更性感的公路照片

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

有一些方法可以繞過它，而不需要使用在執行層涉及VM的方法。如果有一種工具能讓开發者做到這一點呢？

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

那么micro-rollup是真的嗎？

一直都是。(但和rollup一樣真實，抱歉，我不想讓Jon難過)

像Loopring, dYdX和Fuel-v1等應用程序出現或已經存在很長時間了。這些都是超優化的rollup，具有專門運行的自定義邏輯來服務其用例。我所知道並親自參與的第一個非基於虛擬機的特定應用程序rollup是Hubble Optimistic rollup，這個已有3年歷史的項目曾一度作爲Worldcoin代幣的核心基礎設施。(這也是Stackr的主要靈感來源)

只是現在，區分這些術語變得重要起來。

你可以無限制的構建Micro-Rollups：

1.消費產品，如遊戲，交易所，NFT市場等；

2.app-chain可以轉換爲app-rollup；

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

我將撰寫另一篇文章，討論Micro-Rollup的優缺點以及使用Micro-Rollup框架構建哪些應用程序是有意義的。

結論

我前面展示的樹中缺少的元素是自定義狀態機。

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

如果我們修剪這棵樹，最後的樹看起來是這樣的。這也是爲什么我認爲在不久的將來，app-rollup, micro-rollup或rollup將被稱爲Apps的原因。

因此Micro Rollups = Apps on rollups Apps as Rollups

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