打开 Web3 新用例的大门？一文读懂 Micro-Rollups 链上证明
证明是可信赖的信息陈述，用于验证真实性。在Web3世界，数字签名保证证明的真实性和不可变性。Micro-Rollups是可验证的链下计算系统，可与链上应用集成，确保证明的颁发者未篡改系统规则。它可用于EAS链下证明的可验证存储，也可作为可验证的数据账本。通过可验证的计算和汇总状态，Micro-Rollups保证状态转换的正确性，并将数据发布到以太坊L1主网上。使用Stackr的SDK可以轻松构建具有自定义架构和解析器逻辑的新Micro-Rollups，并实现跨Micro-Rollups的互操作性。该系统弥合Web2和Web3之间的差距，保留分布式信任。
原文标题：Micro-Rollups for On-chain Attestations
原文作者：stackrlabs
原文来源：mirror
证明（Attestation），这是一个含义广泛的词，几乎每个人都对它的意思有一些理解，并且每个人在生活中都曾经在不知不觉中使用过这个概念。
那么让我们尝试定义它，证明本质上是对某一信息做出的陈述或声明，它们作为可信赖方提供的证据或确认，以验证特定陈述的真实性。证明的可信度取决于提供证明的实体的声誉，在 Web3 世界中，证明带有数字签名，确保真实性和不可变性。
让我们来看一些例子，无论是现实世界还是加密领域，你可能都没有意识到它们实际上就是某种形式的证明。
Web3 世界的证明：以太坊证明服务登场
以太坊证明服务（Ethereum Attestation Service，EAS）是 Web3 领域支持证明用例的领先项目之一，它是一个开源的基础设施公共产品，用于链上或链下进行证明。EAS 的运作方式非常简单，你只需注册一个关于任何主题的架构（或使用现有的架构），然后根据该架构进行证明。
局限性
尽管 EAS 为 Web3 中的证明推理和利用提供了坚实的基础，但它并非没有局限性。使用 EAS 进行链上证明的成本可能会非常高昂，并且需要编写 EVM 智能合约来实现任何自定义逻辑。对于链下证明，架构仍然需要放在链上，并且开发人员经常将这些证明存储在私有数据库中，从而损害了用户的可验证性。
这种情况凸显了使用 Stackr SDK 构建的 Micro-Rollups 如何用于增强 EAS 或整体证明的功能。
快速介绍 Micro-Rollups
Micro-Rollups 本质上是一种状态机，可以在链下执行特定的逻辑，然后将执行结果的验证外包到另一个称为「Vulcan」的层，而 Vulcan 会更新验证状态并把计算数据上链。
- Micro-Rollups 的状态机具有定义良好的状态格式，并通过创世条件进行初始化；
- 状态机可以执行动作（即交易类型），当触发这些动作时，会调用状态机上的状态转换函数；
- 状态转换函数（STF）负责执行计算并更新状态机的状态；
在 STF 执行后，所有动作将被打包成一个区块并发送到 Vulcan 层。
Vulcan 层会执行以下操作：
- 以「悲观」（Pessimistically）的方式重新执行区块中的动作，以检查状态转换函数（STF）的有效性；
- 为经过验证的区块生成元数据；
- 在 L1（主链）和数据可用性层（DA）上进行结算；
- 将 Micro-Rollups 的更新状态发送到 DA 层；
- 将经过验证的区块的元数据和更新后的状态根哈希值写入 L1 上 Micro-Rollups 的 inbox 合约；
上述流程共同构成了 Stackr 的 Micro-Rollups 框架。
证明系统 Micro-Rollups
那么，为什么 Micro-Rollups 特别适合构建证明系统呢？Micro-Rollups 具有以下优势：
- 可验证的链下计算：Micro-Rollups 在功能上类似于后端服务，但它为应用程序的状态和计算增加了一层可验证性，这可以确保证明的颁发者没有篡改系统规则；
- 可审计的状态：一旦状态机部署完成，状态转换函数（STF）的逻辑就无法被修改，这可以让用户确信提供者不会任意更改系统的规则；
- 可与链上应用集成：Micro-Rollups 可以与链上应用集成，Micro-Rollups 会将应用程序的状态根哈希值写入 L1，其他应用程序可以使用此哈希值来证明性地访问 Rollup 的状态；
Micro-Rollups 用于证明的三种方式
1.EAS 链下证明的可验证存储
如前所述，EAS 的链下证明只是一个包含证明数据和签名的 JSON 文件，这些数据不会存储在链上，而是存储在私有数据库或去中心化存储解决方案中。
与 EAS 推荐的「Ceramic 网络的可验证数据账本」非常相似，Micro-Rollups 是存储这些链下证明的理想解决方案。从本质上讲，Micro-Rollups 是一个可验证的数据账本，因为：
- 可验证的计算确保了状态转换的正确性；
- 状态被「汇总」成一个哈希值（称为 Merkle 根哈希），并在每个 epoch 结束后发布到以太坊 L1 主网上；
- 所有数据都对底层的 DA 层可用；
这样的系统将是一个通用型的 Micro-Rollups，旨在存储针对任何已在 EAS 上注册的架构的证明，同时不会影响最终用户的可验证性。
2.适用于特定架构证明的 Micro-Rollups
其核心即 Micro-Rollups 本质上只是一个由状态和状态转换函数组成的状态机，当通过架构和证明的视角审视这个框架时，我们可以发现一些相似之处。
状态类似于架构，它定义了数据结构，而证明类似于状态转换，它们是经过验证的符合架构的更新，这种对比凸显了 Micro-Rollups 的真正潜力：可以构建针对特定架构的 Micro-Rollups，使证明能够适应特定的架构，并赋予开发人员将自定义逻辑纳入转换函数的灵活性，类似于 EAS 中的解析器合约（Resolver contracts)。
更棒的是，由于计算完全在链下、EVM 之外进行，因此用户在进行证明时无需支付任何 Gas 费。
我们最近的一篇关于 「积分系统 Micro-Rollups」 的文章讨论了应用程序如何利用积分作为激励机制，这正是一个这样的系统的直接例子，因为积分本质上是应用程序授予用户的证明。
还可以使用 Stackr 的 SDK 构建一个封装器，以便轻松启动一个具有自定义架构和解析器逻辑的新 Micro-Rollups，同时保持相同的 API 以实现跨 Micro-Rollups 的互操作性。
3.Micro-Rollups 作为 EAS 的改进方案
由于 Micro-Rollups 可以抽象掉构建去中心化应用的大部分复杂性，因此可以相当快速地将一个接近功能完备的 EAS 替代方案作为 Micro-Rollups 来实现，这种替代方案可以提供相同的三个核心功能：
- 用于存储所有架构的架构注册表；
- 根据架构创建证明的能力；
- 撤销现有证明的选项；
在下一节中，我们将更深入地研究如何构建它。
让我们用 Micro-Rollups 构建一个 EAS
免责声明：此演示展示了框架的功能，代表了一个不完整的构建，不适用于生产环境，请将内容视为说明性而非最终产品。
在开发 Micro-Rollups 时，至关重要的是用状态机的方式来理解您的逻辑，这需要仔细考虑 Micro-Rollups 的状态（即它将持有的数据）以及将支配状态转换函数行为的动作，而状态转换函数又会操作此状态。
关于【打开 Web3 新用例的大门？一文读懂 Micro-Rollups 链上证明】的延伸阅读
Vitalik 谈 L2 与执行分片：有何不同与挑战？
作者认为，以太坊的未来发展需要大量计算和数据带宽。目前，以太坊正在分片，而Rollup是分片的一种形式。未来，所有Rollups可能都会是ZK Rollup，但目前只有Optimistic Rollup和ZK Rollup可用。以太坊的L2方案可以通过不同的数据可用性方法来适应不同的使用情况，但需要权衡安全和交易速度。L2可以实现更快的交易速度，但也面临协调挑战。为了取得成功，需要解决这些挑战，并尽可能获得以太坊L1生态系统的好处。
速览 10 个值得关注的 Eigen AVS 生态项目
EigenLayer推出eigenDA，成为第一个官方验证服务，允许利用以太坊的安全基础，再质押ETH保护其他系统。eigenDA提供高吞吐量和低交易费用，AltLayer与EigenLayer合作开发再质押rollups，提供去中性化验证和快速交易。Omni旨在统一数百种rollups，使用Omni EVM构建的应用程序可以跨多个rollups进行编程。Lagrange构建无需信任的链下计算模块。EigenLayer的Operators确保DePINs项目的状态验证，Eoracle是一个模块化的预言机网络。Drosera利用安全策略防止资产被盗，Ethos为Cosmos链提供解决方案。EigenLayer AVS提供无限可能性，未来还有更多创新。
理解了以上内容，我们现在开始使用 Stackr 的 SDK 设计 Micro-Rollups 的状态。
设计
- 架构和证明存储在状态机内部的链下；
- 用户发送动作，触发状态机内部的状态转换函数；
- 用户可以发送动作来注册架构、针对任何存储的架构创建证明或撤销现有证明；
- 每隔一个既定时间戳就会生成一个区块，其中包含架构和证明状态的详细信息；
- 该区块被发送到 Vulcan 网络进行验证；
- 如果区块符合状态机的规则，则该区块将被批准；
- 区块数据将被拆分到 L1 和 DA 进行结算；
确定初始状态
类似于 EAS，我们需要存储架构和证明的列表。为了清晰地说明这一点并提供明显的对比，我们将使用与 EAS 相同的结构定义。
1.首先，让我们在我们的状态中定义架构和证明。
分析细节如下：
- schemas: 该字段存储了一个哈希映射，键为架构的 UID，值为 SchemaRecord 结构体，SchemaRecord 结构体对应用户提交的证明架构。
- attestations: 该字段存储另一个哈希映射，键为证明的 UID，值为 Attestation 结构体。Attestation 结构体对应引用特定架构的单个证明。
添加状态更新处理程序
在设置了最小可行状态之后，我们需要定义用于更新状态的状态转换函数。
2.让我们定义两个函数：
- schema: 负责创建架构条目；
- attest: 负责创建证明条目；
分析 registerSchema 函数：
- 当用户提交注册新证明架构的指令时，需要提供两个字段：schema：证明架构的 ABI（Application Binary Interface)，revocable：架构是否明确允许撤销证明；
- 发起注册动作的用户将被记录为架构的注册者；
- 状态转换函数会根据提供的数值计算该架构条目的唯一标识符；
- 最后，将新的架构条目添加到状态中；
分析 attest 函数：
- 用户提交创建新证明的指令，其中包含相关 schemaUID 等字段；
- 发起创建动作的用户将被记录为证明者；
- 状态转换函数会根据提供的数值计算该证明条目的唯一标识符；
- 状态转换函数会对比传入的证明数据与相关架构的 ABI；
- 最后，将新的证明条目添加到状态中；
至此，我们已经构建了一个最低可行系统。
智能合约 vs. Micro-Rollups
要获取针对某个架构创建的所有证明，或者由某个地址发出的所有证明，我们就需要遍历所有的证明条目。当我们每次想要进行这样的查找时，都需要重复这一过程。
为了缓解这个问题，EAS 实现了一个名为 Indexer.sol 的智能合约，专门用于索引多个映射变量中的值。然而，由于以太坊虚拟机（EVM）中的存储成本与 Micro-Rollups 相比非常昂贵，这会产生额外的 Gas 费用。
但由于我们正在构建一个 Micro-Rollups，我们可以更加自由地使用状态和计算，以用户体验为优先考虑，而不是成本。
添加索引字段以提高查找效率
3.在状态中添加 schemaAttestations 字段，该字段将用于维护架构与其证明之间的映射关系。
因此，当添加新的证明时，我们也更新 attest 函数，以更新架构的映射关系。
这样就可以轻松构建一个类似于以太坊证明服务的可追溯性的链上证明系统，赋予后端服务器链上超能力，听起来是不是很简单？
将链下证明引入链上 → 现实世界用例和更多可能
在 Web3 世界中，证明对于启用大多数现实世界用例至关重要，它们弥合了 Web2 和现实身份与 Web3 之间的差距，保留了分布式信任。
上述系统的妙处在于，它允许证明在链上无缝使用，而不会产生大量开销。
正如开头所提到的，Micro-Rollups 的状态根会结算在 L1 上。值得注意的是，开发人员可以选择哪些状态部分结算在 L1 上，哪些部分作为元数据放在 DA 上，从而解锁混合安全假设。
在这种情况下，如果我们提取证明并将其默克尔根（merklized root）结算在 L1 上，那么我们就可以在默克尔树中进行证明的直接包含性证明。
这一特性解锁了链上身份验证、所有权证明以及访问各种服务和权益的功能。例如，摩根大通最近使用了一种名为可验证凭证的证明形式来执行其在公共区块链上的首笔 DeFi 交易。当证明数据连同包含性证明一起引入链上时，链上现实世界用例的潜力将呈爆炸式增长。
这种方法使证明可以在链上进行验证，而无需将证明严格存储在链上，并且成本更低，用户体验更佳。
总结
虽然证明在 Web3 中看起来像是一种新事物，但它们一直是我们所感知的 「信任体验」 的一部分。它们对于将现实世界的身份和资产引入链上至关重要，这直接促进了区块链的合法性。从本质上讲，证明只是人类协调的另一种工具。有了这种心智模型，只剩下一个问题：我们如何在网络层面进行协调？
Micro-Rollups 凭借其可验证和快速的链下计算、可审计状态以及与链上应用集成的能力，为构建强大的证明系统以及协调机制提供了理想的框架。
我们才刚刚开始弥合 Web2 和 Web3 之间的差距。
免责声明：本文仅代表作者个人观点，不代表链观CHAINLOOK立场，不承担法律责任。文章及观点也不构成投资意见。请用户理性看待市场风险，以及遵守所在国家和地区的相关法律法规。
图文来源：stackrlabs，如有侵权请联系删除。转载或引用请注明文章出处！
