探索Mina的獨特架構和zkApp應用例子

<!--StartFragment-->

Mina 架構簡介

每個 Mina 智能合約的帳戶可容納 8 個任意字段的元素。每個字段的大小大約為 32 個bytes。這看起來可能不多，但考慮到在底層，以太坊使用了類似的機制，其中一個元素（world state trie）引用了儲存在其他地方的任意數量的合約狀態。該引用字段稱為 storageRoot，顧名思義，它保存包含合約帳戶所有存儲狀態（the Account Storage trie）的 trie 的root hash。 Mina 合約帳戶上的 8 個字段元素中的每一個都類似於以太坊的 storageRoot，能夠保存對儲存在其他地方的任意數量的資料的承諾。以太坊將所有這些額外的狀態嘗試作為全域網路狀態，並為您管理它（需要gas成本）。然而Mina卻沒有。您需要將自己的資料結構儲存在鏈下，並將這些結構提交到鏈上帳戶的狀態字段中。這通常是透過將實際狀態保存在 Merkle 樹中並將該樹的root hash儲存在帳戶字段之一中來完成的。它的機制基本上相同，但與網路分離。無論使用多少儲存量，這都允許固定的交易成本。

Mina 本質上是一個證明驗證層。例如鏈下計算和固定交易費用，但這只是一部分。 Mina 上的 zkApps 為開發人員提供了產生、排序和驗證事物證明的能力。例如身份、社區中身份驗證、簽名方案或其他網路的匯總狀態等等。當您提交 zkApp 的交易時，Mina 會對您的證明進行排序及將它們與其他證明組合起來，以創建迄今為止提交到網路對所有事實的單一聚合驗證。可以將您的自訂證明轉化為進一步的證明，然後同以驗證交易、區塊生產以及最終的整個網路狀態。類似的遞歸可組合性功能也掌握在您的手中。這意味著您可以採用無需信任、分散且去中心化的方式來建立可組合證明並對其進行排序。您可以建立一個既是獨立事實陳述的應用程序，也可以是由社群創建的更大和可驗證計算的一個片段。

Mina 特別的地方是某些狀態可以保留在區塊鏈上，但只要它被包裝在零知識電路中，執行計算的動作就可以在任何地方執行。 而 o1js 可以允許開發人員編寫在最終用戶的瀏覽器中執行的應用程序，但依然可靠地將狀態提交到公共帳簿。因為狀態的改變是由原計算的有效性證明授權的，而不是由執行計算的環境來授權。

在交易中是如何發揮作用?

Mina 不是 RPC，當與用 o1js 編寫的 zkApp 互動時，並不是要求區塊鏈執行智能合約中的方法。當一個交易提交給 Mina 時，相對應的方法已經被呼叫。同一時間應用邏輯已在零知識電路內執行。只要滿足電路中定義的所有約束，交易就可以簡單地描述一組應應用於公共帳簿的狀態更改，還有在零知識證明之下可以表明這些更改是可以信任。 Mina 協議只是驗證證明，如果證明有效，則將這些變更提交到公共帳簿。所以可以看到計算和狀態已經分離。這使得每個 zkApp 都成為一個匯總(rollup)，因為網路狀態變化被證明是源自於任何地方。這就是為去中心化應用程式提供固定交易費用的原因。這也是為什麼獨特的 Action/Reducer 模型對於管理排序和並發存取狀態是必要的。

排序(Sequencing)、動作(Actions)和減速器(Reducers)

排序在任何分散式系統中都是一個關鍵挑戰。在區塊鏈中，區塊生產者決定交易的次序。應用程式開發人員無法控制此次序，並且必須將其交易設計為可交換的（可按任何順序處理），因為影響狀態的計算發生在交易排序之後。在基於 Mina 創建的 zkApps 中，計算發生在鏈下，甚至在交易提交之前。可惜的是交換性是不夠的，因為不單是順序不受我們的控制，而且在計算發生時它甚至還沒有確定。

那我們要如何在沒有競爭條件的情況下改變狀態呢？

利用動作(actions)和減速器(reducers)。 zkApps 應該發布一個包含稍後時間更改狀態所需的資料的操作，而不是直接更改狀態。這讓協議有機會在處理這些操作之前對操作進行排序。然後在一個單獨的過程使用一個減速器來消耗這些操作及處理它們，並在另一個交易中提交最終狀態。基本上是拆分聚合步驟並在完成排序之後才執行它。

原文: <https://www.o1labs.org/blog/exploring-minas-unique-architecture>

<!--EndFragment-->