当应用程序成为 Rollup Micro-Rollup 会是下一波浪潮吗？

用诸如「什么是 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。