Micro-Rollup：一波浪潮还是一个无耻的营销术语？

我的一条推文最近火了，在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