探索Mina的独特架构和zkapp范例
Mina有点不同。我们为此感到自豪。但它也可能是困惑的来源。在这篇文章中，我们将对由o1js和Mina协议支持的zkApps中的状态和计算是如何工作的进行一个高层次的概述，为什么某些非典型的设计模式是必要的，以及这如何带来独特的机会。
在传统的web2架构中，应用程序通常可以不受限制地访问某种私有数据库。它们直接执行计算和修改状态值。这通常由一个权限方案实现，并在基础设施层面通过环境变量或者专用网络进行管理。这些凭据指定哪些进程或运行时允许改变状态。这意味着，即使基础设施是分布式的，计算和状态在概念上也被绑定在一个可信关系中。在很多情况下，这是直观和合理的。
Web3应用程序架构引入了公共的、非中间化的基础设施。这很棒，但它并没有从根本上改变计算和状态之间的关系。这些应用程序仍然被授权根据其区域设置操纵状态;只有在区块链上运行的代码才能改变链状态。这就是为什么我们有远程过程调用(RPC)方法调用和gas模型。我们需要花钱请人在正确的地方运行代码，这样它就可以改变状态。这也是为什么计算会在整个网络上重复，从而导致巨大的浪费和高额的交易费用。
这就是Mina不同的地方。有些状态保留在区块链上(我们将回到这一点)，但计算可以在任何地方执行，只要它被包裹在零知识电路中。O1js允许开发人员编写在终端用户浏览器中执行的应用程序，但仍然可靠地将状态提交到公共分类账。这是可能的，因为状态更改是根据原始计算的有效性证明而授权的，而不是执行计算的环境。我们认为这很酷。
让我们看看这在交易中是如何发挥作用的。正如我们已经暗示的，它们不是rpc。当有人与用o1js编写的zkApp交互时，他们不会要求区块链运行某个智能合约方法。当交易被提交给Mina时，该合约方法已经被调用。应用逻辑已经在零知识电路中执行。只要电路中定义的所有约束都已经满足，交易就只是描述了一组应该应用于账本的状态变更，以及附带一个零知识证明来表明这些变更是可信的。Mina协议只是简单地验证证明，如果证明有效，则将这些更改提交到账本。可见，计算和状态已经分离！这使得每个zkApp都有点像一个Rollup，因为网络状态的变化被证明是源自其他地方。这就是(Mina上的)Dapps能够实现固定交易费用的原因。这也是为什么我们独特的Action/Reducer模型需要管理对状态的顺序和并发访问，所以让我们深入研究一下。
Sequencing, Actions and Reducers
排序在任何分布式系统中都是一个关键的挑战。在区块链中，区块生产者决定交易的顺序。应用程序开发人员无法控制这个顺序，必须将他们的事务设计成可交换的(可以以任何顺序处理)，因为影响状态的计算发生在事务排序之后。在基于Mina构建的zkApps中，计算发生在链下，在交易提交之前。仅有可交换性还不够，因为不仅顺序超出了我们的控制，甚至我们还不确定计算何时发生。那么我们如何在没有竞争条件的情况下改变状态呢?使用Actions和Reducer。zkApps应该发布一个包含稍后更改所需数据的action，而不是直接更改状态。这让协议有机会在处理这些操作之前对它们进行排序。然后，一个单独的进程——智能合约上的另一个方法——使用一个reducer来消耗这些操作，处理它们，并在另一个事务中提交最终状态。我们基本上是将聚合步骤分开，并在排序完成后执行它。在这个意义上，它有点像map/reduce。
让我们进一步理解这个存储状态的想法，因为它的处理方式也略有不同。每个Mina智能合约账户可以持有8个任意字段元素。每个字段大约是32字节。这可能看起来不多，但考虑到背后的原理，以太坊使用了类似的机制，具有单个字段(在世界状态树中)，该字段引用存储在其他地方的任意数量的合约状态。该引用字段称为storageRoot，顾名思义，它保存了一个trie树的根哈希，该trie树包含合同帐户的所有存储状态(帐户存储trie树)。Mina合约账户上的8个字段元素中的每一个都像以太坊的storageRoot，能够持有存储在其他地方的任意数量的数据的承诺。以太坊将所有这些额外的状态尝试作为全局网络状态提供，并为您管理它(包括汽油成本)。然而，米娜却没有。你需要在链下存储自己的数据结构，并在链上的账户状态字段中提交这些结构。这通常通过将实际状态保存在Merkle树中，并将树的根哈希存储在account字段中来实现。它基本上是相同的机制，但与网络解耦。这允许固定的交易成本，无论使用了多少存储。
Proof of Everything
那么，为什么这些都很酷呢？毕竟，这对应用开发者来说需要更多的努力。那么回报是什么呢？为了回答这个问题，我们需要退一步来看。Mina 本质上是一个证明验证层。我们刚刚展示了如何利用这一点，通过一些非常有趣的特性（如链下计算和固定交易费用）实现类似智能合约的行为，但这只是故事的一部分。让我们先把这些放在一边，更抽象地看一下设计。Mina 上的 zkApps 赋予开发者生成、排序和验证各种证明的能力。比如身份、社区成员资格、签名方案或其他网络的汇总状态。实际上，任何计算都可以。非常有趣。
当你提交一个 zkApp 交易时，Mina 会对你的证明进行排序，并将它们与其他证明组合，创建一个单一的、聚合的验证，涵盖迄今为止提交给网络的所有事实。我们将你的自定义证明汇总成进一步的证明，以验证交易应用、区块生成，并最终验证整个网络状态。你也可以使用类似的递归组合能力。这意味着你有一种无需信任、分布式且去中心化的方式来创建和排序可组合的证明。你可以构建既是独立的事实声明，又是更大、可验证计算片段的应用，这些计算片段由社区根据需要创建。
我们认为这非常酷，并且展示了巨大的、尚未被发现的可能性。确实有些不同，但我们认为这非常强大。我们迫不及待地想看看你能用它构建什么。
加入Mina社区并探索我们的开发者资源，用Mina的一切证明来帮助构建一个更好的未来。
