【Mina Protocol】世界最小22KBのブロックチェーンの仕組み
本記事の概要
Mina Protocol についてよく耳にする特徴といえば 世界最小の 22KB のブロックチェーンですが、ではその 22KB にはいったい何が含まれているのかや、どのよう仕組みで動いているのかという点を中心に整理しました。
Mina Protocol とは
Mina Protocol（ミナ・プロトコル）は、ブロックチェーンのスケーラビリティと分散性の課題を解決することを目指したブロックチェーンです。一番の特長はブロックチェーン全体のサイズがわずか 22KB に保たれている点です。これによりスマートフォンなど比較的容量の少ないデバイスでもノードとしてネットワークに参加でき、誰でも手軽にブロックチェーンを利用することができます。
Mina Protocol の軽量性を実現しているのが、ゼロ知識証明の一種である SNARK（Succinct Non-Interactive Arguments of Knowledge） 技術です。この技術を活用することでブロックチェーン全体の履歴を圧縮し、トランザクションを効率的かつ安全に検証可能にしています。
Bitcoin や Ethereum が数百 GB であるのに比べて非常に軽量です。これによりユーザーはモバイル端末などからでも負担なくネットワークに参加でき、より分散化されたブロックチェーンの実現が期待できます。
多くのブロックチェーンはサイズが増大するが、Mina は一定サイズで僅か 22KB
ブロックチェーンに保存されるデータ
22KB の中身は何かを順に確認していきましょう。ちなみに現在は最適化が進み全体で11KB程度しかないようです。
SNARK 証明
新しく発生したトランザクションに関する SNARK 証明と、直前のブロックまでに含まれていたトランザクションをまとめた SNARK 証明が最新のブロックには含まれます。次のブロックを生成する際には、この2つの証明から新たな証明を作り含めることで、ブロックチェーンを一定サイズに保っています。
Protocol State
現在のネットワーク全体の状態を表したものです。ここには ledger など様々なデータのハッシュ値が含まれます。
最新のブロックには 前述の SNARK 証明と Protocol Stateが含まれており、これによりブロックチェーン全体の検証が可能となります。
Account
Mina は Ethereum のようにアカウントベースモデルを採用しています。そのため公開鍵に対応する残高の情報はアカウントレコードに保存されます。
Merkle path to an account（アカウントへのマークルパス）
Mina Protocol では、アカウントの残高やデータは Merkle Tree（マークルツリー）というデータ構造に格納されています。このツリーの最上位にあるハッシュ値が Merkle Root（マークルルート） です。ノードはアカウントデータと Merkle Path を使って Merkle Root を計算し、これが SNARK によって検証された ledger の状態と一致すればそのデータは正しいと保証されます。
ノードの種類
Mina Protocol でのノードとは Mina daemon を実行しているマシンのことを指します。
役割に応じていくつか種類があります。
Block Producer（ブロックプロデューサー）
どのブロックの生成を許可するかのプロセスに参加し、その後トランザクションを含むブロックを生成してネットワークに送信するノードです。
SNARK Coordinators（SNARK コーディネーター）
Mina Protocol のノード内での役割の一つで、ブロック生成と並行して複数の SNARK Worker に作業を分散させます。
SNARK Workers
各トランザクションに対して zk-SNARK を生成する役割を担います。これらの zk-SNARK は、ブロックの正当性を証明するために使用され、その後、ネットワーク全体の正当性を証明する再帰的 zk-SNARK を生成します。
Archive Nodes
Mina daemon による通常のノードで、稼働中の mina-archive プロセスに接続されています。この daemon はブロックチェーンデータを定期的にアーカイブプロセスに送信し、PostgreSQL データベースに保存します。
Seed Nodes
ネットワーク内のノードの記録を保持し、ネットワークに参加するノードが他のノードに接続できるようにします。Seed Nodes への報酬の支払いはなく、コミュニティ手動で運営されています。
ハードウェアの要件
ノード運用のためのハードウェア要件は以下のようになります。Ethereum などであればストレージに1TB程度求められることを考えるとかなり軽量です。
| Node Type | Memory | CPU | Storage | Network |
|---|---|---|---|---|
| Mina Daemon Node | 32 GB RAM | 8コアプロセッサ（BMI2およびAVX CPU命令セットが必要） | 64 GB | 1 Mbps インターネット接続 |
| SNARK Coordinator | 32 GB RAM | 8コアプロセッサ | 64 GB | 1 Mbps インターネット接続 |
| SNARK Worker | 32 GB RAM | 4コア/8スレッド（BMI2およびAVX CPU命令セットが必要） | 64 GB | 1 Mbps インターネット接続 |
| Archive Node | 32 GB RAM | 8コアプロセッサ | 64 GB | 1 Mbps インターネット接続 |
| Rosetta API standalone Docker image | 32 GB RAM | 8コアプロセッサ | 64 GB | 1 Mbps インターネット接続 |
| Mina Seed Node | 64 GB RAM | 8コアプロセッサ | 64 GB | 1 Mbps インターネット接続 |
トランザクション実行の流れ
Mina Protocol でのトランザクション実行の流れを説明します。
ここでは Bob が Alice にいくらかの MINA を送るケースを考えます。
1. payment transaction の作成と送信
誰でも payment transaction（以降 tx とします）を作成し Mina ネットワークに送信することができます。tx は秘密鍵で暗号署名されるため、送信者のアカウントは検証可能となります。tx はネットワーク上のノードに送信され処理されます。ノードが受け取った tx は、ノードのローカル環境にある transaction pool に置かれます。
2. ブロック生成
どのノードがブロックプロデューサーになるかは slot time である約3分毎にネットワーク上で選択されます。現在アクティブなブロックプロデューサーは進行中の各トランザクションの fee（手数料）に基づいてトランザクションをいくつか選択し、それらをトランジションブロック（トランザクションブロックではありません）と呼ばれる処理対象のリストに配置します。
ブロックプロデューサーはこれらのブロックを生成することで $MINA を稼ぐことができます。
ブロックプロデューサーは以前のブロックと比較してトランジションブロックの構造を定義する SNARK を生成します。（注意点として、この時点では Bob の送金トランザクションである tx を含む新しいトランザクションはまだ検証されていません。）その後、ブロックプロデューサーはこの新しい情報を SNARK Worker が処理できるように送信します。
3. ボブの支払いの SNARK 証明に対する署名を作成
ネットワーク上の SNARK Worker ノードは、新しいトランジションブロックの各ステップに対して SNARK 計算を開始します。これらは各支払いの個別の証明を行い、その後、隣接する支払いの証明を統合します。最終的にすべての支払いが検証されます。
SNARK Worker はこれらの証明を生成することで通貨を稼ぐことができ、報酬はブロックプロデューサーがブロック報酬から支払います。生成されたこれらの証明はネットワーク上に送信されます。
4. Bob と Alice のアカウントの残高変更の確認メッセージを送信
ブロック全体が証明された後、ブロックプロデューサーはトランジションブロックの確認メッセージをネットワークに送信します。その後、ネットワーク上のメンバーノードはブロックを検証し、問題なければ自身のローカルアカウント残高に変更を適用してこれらの変化を反映させます。これで支払いの処理は完了です。
5. 支払いの確定
4.までで支払いの処理は完了しましたが、直後は結果が覆る可能性があります。他のブロックチェーンと同様に、時間が経ち次のブロック、またその次のブロックが追加されるごとにトランザクションが確定した可能性が高まります。これをトランザクションの確定性（ファイナリティ）と呼びます。
slot time が約3分で悪意あるバリデータが10%と仮定した場合のブロックの確定性、対応するブロック数を生成する平均時間、支払いが確認される確率が以下の表のようになります。
| ブロック数) | ファイナリティまでの平均時間 | ファイナリティの信頼性 (%) |
|---|---|---|
| 8 | 33分 | 98.6709 |
| 15 | 60分 | 99.9231 |
| 23 | 1時間32分 | 99.9965 |
| 30 | 2時間 | 99.9998 |
| 38 | 2時間分 | 100 |
世界最小である 22KB のブロックチェーン
Mina Protocol はジェネシスから任意のブロックまでのブロックチェーン全体を、簡単に検証可能な一定サイズの SNARK 証明に置き換えます。この証明を検証することは、現在のブロックの少し前までの全トランザクションを検証することに相当します。そして証明と検証関数への入力は最新のブロックに含まれており、それがネットワーク上で広まります。つまり、先ほどご紹介したように最新のブロックさえあれば、そこに含まれる証明を利用してチェーン全体を検証することが可能になります。
一方でビットコインやイーサリアムなどの他のネットワークでは、現在の状態の検証にはマイナーはネットワーク内のすべての取引履歴を必要とします。これは、アカウントベースや UTXO ベースのネットワークでも同様です。新しいノード（または長期間オフラインだったノード）は信頼性のある方法でネットワークに同期するために、オフラインだった間全てのブロックをダウンロードする必要があります。
このようにしてブロックチェーンとしての標準的な機能は持ちつつ、 Mina Protocol は世界最小のブロックチェーンを実現しているのです。
超軽量な非コンセンサスノード（Non-Consensus Node）
軽量なブロックチェーンという特徴を活かして
・特定のアカウントの残高を確認
・ネットワークに取引を送信
の機能を有する超軽量なノードの開発も計画されています。このノードのことを "Non-Consensus Node" と呼びます。大事な点はこのノードもブロックチェーン全体、すなわち Protocol State、アカウント、アカウントへのマークルパス、そして検証キーを保有しているため、他のチェーンのライトクライアントとは違い、フルノードと同等のセキュリティを持っている点です。
Mina Protocol の軽量なブロックチェーンに含まれるデータと、その仕組みを実現するための Mina Protocol 特有の概念をご紹介しました。
本記事で取り上げた内容は全体のほんの一部ですので、興味を持っていただいた方はぜひ以下の公式ドキュメントもご確認ください！
Discussion