はじめに
Zama は、Series A の $73M と Series B の $57M を合わせ、累計で約 $130M を調達している FHE 分野の有力企業です。現在は mainnet が公開されており、機密計算をブロックチェーン上に持ち込むための実装レイヤーとして注目を集めています。
弊社 Omakase も、Zama Protocol における 13 社の MPC partner の一社として選定されています。本記事では、その事実を前提にしつつも、内容自体は技術とプロダクトの観点から整理します。
本稿で扱う論点は、次の 4 点です。
- FHE とは何か。ZK とは何が違うのか
- なぜ Zama がプライバシー領域で有力候補だと考えているのか
- $ZAMA の設計上の役割を含む Zama Protocol のアーキテクチャ
- 今後のロードマップを考えるうえで、利用者や開発者が今確認しておきたいこと
FHE とは何か。ZK とは何が違うのか
FHE は Fully Homomorphic Encryption の略で、データを暗号化したまま計算できる技術です。通常の暗号方式では、任意の計算を行うにはいったん復号する必要がありますが、FHE では実行中も平文を出さずに計算を続けられます。
ブロックチェーン文脈では、この性質が重要です。例えば送金であれば、残高や送金額を公開せずに残高更新を行う、といった設計が可能になります。計算対象そのものを隠したまま状態遷移を進められることが、FHE の中心的な価値です。
一方、ZK（Zero-Knowledge Proof, ゼロ知識証明）は、入力の中身を明かさずに「ある計算が正しく実行された」ことを第三者が検証できる技術です。したがって、ZK の主眼は正しさの証明であり、FHE の主眼は秘匿されたまま計算を継続することにあります。
この 2 つは競合というより補完関係にあります。FHE で秘匿実行を行い、ZK で入力の妥当性や処理の正当性を補強する構成は自然です。Zama Protocol も、FHE を中核に据えつつ、入力検証やシステム全体の成立性を支えるために ZK、MPC、TEE を組み合わせています。
なぜ Zama が有力候補だと考えているのか
Zama を有力候補だと考える理由は、単に FHE を使っているからではありません。研究、実装、開発者体験、そしてプロトコル設計が一つにつながっている点にあります。
まず研究面では、CTO の Pascal Paillier 氏が暗号学の権威であり、Paillier 暗号の発明者として知られています。CEO の Rand Hindi 氏も連続起業家としての実績があり、研究チームの強さと事業推進力の両方を持つことが Zama の土台になっています。
次に、Zama は単なる研究会社ではなく、オープンソースのライブラリと開発環境を通じてエコシステムを拡張しています。web3 の FHE プロジェクトである Fhenix や Mind Network も Zama の OSS を利用してきた経緯があり、FHE 領域の共通基盤としての存在感が強いと言えます。
開発者体験の面でも、Zama の優位性は大きいと考えています。FHEVM によって、Solidity ベースの既存開発フローに近い形で機密計算を組み込めるからです。従来であれば、プライバシー機能を入れるために専用チェーンや独自実装を前提とすることが多くありましたが、Zama は既存の L1 / L2 の上に confidentiality layer を載せる考え方を取っています。
この設計は、企業導入の観点でも重要です。新しいチェーンへの移行を前提にするのではなく、既存の Ethereum 系資産や EVM 開発資産を活かしながら、必要な箇所にだけ秘匿計算を導入できるためです。制度面、監査面、既存運用との接続を考えると、この差は大きいと見ています。
Zama Protocol のアーキテクチャ
Zama Protocol は、FHE だけで完結するシステムではありません。FHE、ZK、MPC、TEE をそれぞれ役割ごとに分担させることで、秘匿性、検証可能性、分散性、実運用性を両立しようとしています。
大まかな構成要素は、Host Chain、Confidential Smart Contract、Coprocessor、Gateway、KMS、Oracle / Relayer です。
- Host Chain: Ethereum など、アプリケーション本体が展開される L1 / L2
- Confidential Smart Contract: 暗号化ハンドルを参照し、FHE 計算命令を出すコントラクト
- Coprocessor: オフチェーンで FHE 計算や入力検証を行うノード群
- Gateway: 入力検証、ACL 同期、復号要求、コンセンサス集約を行う中核レイヤー
- KMS: MPC によって秘密鍵断片を分散保持し、しきい値復号を行うノード群
- Oracle / Relayer: コントラクトやユーザーと Gateway の接続を簡略化するインターフェース
以下、トランザクションの流れに沿って整理します。
1. 機密データの登録
ユーザーは、まず平文データを FHE 公開鍵で暗号化します。その際、暗号文が正しく作られていることを示す ZK Proof of Knowledge を添えて登録します。これにより、「暗号化された値が正しい形式であり、送信者がその中身を知っている」ことを検証できます。
その後、Coprocessor 群が証明を検証し、Gateway が多数決に近い形で結果を集約して、暗号化データを参照するハンドルを発行します。オンチェーンのコントラクトは平文を持たず、このハンドルを通じて暗号化状態を扱います。
2. ACL の設定
Zama Protocol では、暗号化データを誰が計算・復号できるかを ACL で管理します。機密コントラクトが allow や allowForDecryption に相当する権限を設定し、その情報が Coprocessor と Gateway に同期されます。
この ACL があることで、暗号化データは存在していても、誰でも勝手に復号できるわけではありません。秘匿データに対して、どのコントラクトが計算できるか、どのアドレスが復号結果を受け取れるかを明示的に制御できます。
3. FHE 計算の実行
ユーザーが Host Chain 上の機密コントラクトにトランザクションを送ると、コントラクトはハンドル同士に対する FHE 演算命令を発行します。加算、比較、条件分岐のような処理は、オンチェーンで平文を扱うのではなく、オフチェーンの Coprocessor が暗号文に対して実行します。
Coprocessor は計算結果となる新しいハンドルを返し、Gateway がその整合性を集約し、コントラクトが参照するハンドルを更新します。重要なのは、この間に平文を公開しないことです。オンチェーンには「何を計算したか」の命令は出ますが、「計算対象の中身」は出ません。
4. 必要な場合のみ復号
平文が必要になる場合は、ユーザーまたはコントラクトが復号を要求します。Gateway は ACL を確認したうえで、KMS に対してしきい値復号を依頼します。
KMS は MPC ノード群で構成されており、各ノードは秘密鍵の断片だけを持ちます。これにより、単一ノードや単一運営者が秘密鍵全体を握る構造を避けています。さらに、各ノードは TEE で保護された実行環境を前提とし、運営者自身も内容に直接触れられない設計が採られています。
ユーザー向けの復号では、平文をそのまま返すのではなく、ユーザーの公開鍵で再暗号化したうえで Relayer 経由で返送するフローが取られます。つまり、復号結果にアクセスできる主体も限定されます。
$ZAMA の設計上の役割
Zama Protocol の設計上、$ZAMA は単なる投機用トークンではなく、プロトコル運営のためのユーティリティを担います。主な役割は、手数料、ステーキング、ガバナンスです。
まず手数料の面では、暗号化入力の検証、復号、ブリッジのような処理に対してプロトコル手数料が設定されます。アプリ開発者やリレイヤーが肩代わりする設計も可能ですが、プロトコルとしてはこれらの操作に経済的コストを割り当てる構造です。
次に、Coprocessor やオペレーターは $ZAMA をステークし、正しく振る舞うインセンティブを持ちます。不正や不適切な挙動があった場合にはスラッシング対象となりうるため、暗号学的な安全性だけでなく経済的な安全性も補強されています。
さらに、ガバナンス面では、インフレ率やスラッシング判断を含む一部の重要パラメータにトークン保有者が関与する設計が示されています。したがって、$ZAMA は「使う」「預ける」「意思決定に参加する」という三つの役割を持つことになります。
今後のロードマップを考えるうえで見ておきたい点
今後の Zama を見るうえで重要なのは、単に「FHE がすごいか」ではなく、どの用途から先に定着していくかです。特に相性が良いのは、機密トークン、プライベートな送金、オークション、オンチェーンの信用スコアや審査、ID やコンプライアンス連携といった領域です。
理由は明確です。これらのユースケースでは、公開検証性を保ちたい一方で、残高、価格、属性、入札額といった情報は公開したくないからです。従来のパブリックチェーンでは、この二つを同時に満たすことが難しかったため、FHE の価値が直接出やすい領域だと考えられます。
利用者や開発者が今できることも、比較的はっきりしています。
- 自分たちのユースケースで、本当に隠したいデータが何かを整理する
- その要件が、ZK 単体で足りるのか、FHE が必要なのかを切り分ける
- 既存の Solidity / EVM 資産を活かせるかを確認する
- 復号権限、ACL、運用責任分界まで含めてアプリ設計を考える
- ノード運営、MPC、監査対応を含む実装体制を早い段階で検討する
プライバシー領域は、概念だけ追っていても理解しづらい分野です。どのデータを隠し、誰にだけ見せ、どこまでをオンチェーンに残すかという設計に落ちたときに、初めて技術選定の差が見えてきます。
まとめ
FHE は、暗号化したまま計算できるという点で、ブロックチェーンのプライバシー設計を大きく変える可能性があります。ZK が「正しさの証明」を担うのに対し、FHE は「秘匿状態のまま計算を進める」ことに強みがあります。
その中で Zama は、研究者主導の技術的強みだけでなく、FHEVM、Coprocessor、Gateway、KMS、ACL を含むプロトコル全体を開発者が使える形に落としている点が強いと考えています。既存の L1 / L2 の上で confidentiality layer を実装できることも、導入面で大きな意味があります。
Zama は今後のプライバシー領域における有力候補の一社です。特に、企業や金融系ユースケースのように「公開検証性」と「秘匿性」を同時に求める場面では、今後さらに存在感が高まると見ています。