聖杯のデコード：チェーン上完全準同型暗号の課題と解決策
TechFlow厳選深潮セレクト
聖杯のデコード：チェーン上完全準同型暗号の課題と解決策
完全準同型暗号（FHE）は「暗号技術の聖杯」と称されるが、現時点ではパフォーマンス、開発体験、セキュリティの面で制限があり、実用化が難しい。
Web3業界の深掘り報道に専念し潮流を洞察
主要見解
・完全準同型暗号（FHE）は「暗号技術の聖杯」と称されるが、現時点ではパフォーマンス、開発体験、セキュリティの面で制約がある。
・上図に示すように、真に機密性が保たれ、安全な共有状態システムを構築するには、FHEをゼロ知識証明（ZKPs）およびマルチパーティ計算（MPC）と組み合わせる必要がある。
・FHEは急速に進展しており、新しいコンパイラーやライブラリー、ハードウェアの開発、またインテル、グーグル、DARPAといったWeb2企業による研究開発がその発展を大きく後押ししている。
・FHEおよびその周辺エコシステムが成熟するにつれて、「検証可能なFHE」が標準になると予想される。分散アプリケーション（DApps）／ロールアップは、計算と検証をFHEコプロセッサーに外部委託する可能性がある。
・オンチェーンFHEにおける基本的な制限は「誰が復号鍵を持っているか」という点である。しきい値復号（Threshold decryption）やMPCはこの制限に対する解決策を提供するが、通常、性能とセキュリティの間でトレードオフが生じる。
はじめに
ブロックチェーンの透明性は二面性を持つ。オープンで観測可能であることは魅力的だが、企業がブロックチェーン技術を採用する際の懸念材料にもなる。
オンチェーンプライバシーは、ここ10年間、暗号分野で最も困難な課題の一つとされてきた。ゼロ知識証明（ZKP）に基づくシステムを開発しているチームは多数存在するが、それらは暗号化された共有状態をサポートできない。理由は、これらのスキームが一連のZKP関数にすぎず、現在の状態に対して任意のロジックを適用することが不可能だからである。つまり、単にZKPだけを使って暗号化された共有状態アプリケーション（例：非公開Uniswap）を構築することはできない。
しかし最近の技術的進展により、ZKPと完全準同型暗号（FHE）を組み合わせることで、完全に汎用的かつ暗号化された分散型金融（DeFi）を実現できることが示されている。これはどのように実現されるのか？ FHEは暗号データ上で任意の計算を可能にする新興の暗号技術である。上図に示すように、ZKPはユーザー入力と計算の整合性を証明し、FHEは計算自体を処理する。
FHEは「暗号技術の聖杯」と称されるが、本稿ではこの分野の客観的分析とともに、さまざまな課題とその解決策について考察したい。本技術レポートでは、以下のオンチェーンFHEに関するトピックを扱う：
1. FHEスキーム、ライブラリー、コンパイラー（FHE Schemes, Libraries and Compilers）
2. セキュアなしきい値復号（Secure Threshold Decryption）
3. ユーザー入力と計算当事者のためのZKP（ZKPs for User Inputs + Computing Party）
4. プログラマブルでスケーラブルなデータ可用性（DA）レイヤー（Programmable, Scalable DA Layer）
5. FHEハードウェア（FHE Hardware）
完全準同型暗号（FHE）スキーム、ライブラリー、コンパイラー
課題：新興のFHEスキーム、ライブラリー、コンパイラー
オンチェーンFHEの基本的なボトルネックは、開発ツールとインフラの遅れにある。ゼロ知識証明（ZKP）やマルチパーティ計算（MPC）とは異なり、FHEは2009年以来の比較的新しい分野であり、成熟度が低い。
FHE開発体験における主な制約は次の通り：
・バックエンドの暗号理論を深く理解しなくてもコーディングできる、使いやすいフロントエンド言語の欠如。
・パラメータ選択、BGV/BFVのSIMD最適化、並列最適化など複雑な作業をすべて処理できる機能豊富なFHEコンパイラーの不足。
・既存のFHEスキーム（特にTFHE）は通常の計算に比べて約1000倍遅い。
FHE統合の複雑さを理解するために、開発者が経験するプロセスを見てみよう：
FHEをアプリケーションに統合する最初のステップは、FHEスキームを選択することである。下表は主なスキームを説明している：
上表に示すように、ブール回路（FHEWやTFHEなど）はブートストラップ速度が最も速く、複雑なパラメータ選択を回避でき、任意／汎用計算に使用できるが、相対的に遅い。一方、BGV/BFVは高精度算術計算に効率的であり、一般的なDeFiアプリケーションに適しているが、スキームのすべてのパラメータを設定するためには、あらかじめ回路の深さを把握しておく必要がある。CKKSは準同型乗算をサポートし、精度誤差を許容するため、機械学習などの不正確な用途に適している。
開発者として、FHEスキームの選択には非常に慎重になる必要がある。なぜなら、それは他のすべての設計決定と将来のパフォーマンスに影響を与えるからである。さらに、モジュラスの大きさや多項式の次数など、FHEスキームを正しく設定するために重要ないくつかのパラメータがある。
次にライブラリーについて、以下は現在よく使われているFHEライブラリーの機能と能力を示す：
しかし、これらのライブラリーは異なるFHEスキームやコンパイラーとそれぞれ異なる関係を持っている：
FHEスキームを選択した後、開発者はパラメータを設定する必要がある。正しいパラメータ選択はFHEスキームのパフォーマンスに大きな影響を与える。問題は、これを正しく行うには抽象代数学、再線形化やモジュラス切替といったFHE特有の操作、および算術またはバイナリ回路についての理解が必要となる点である。最終的には、FHEスキームへの影響を概念的に理解した上で、効果的にパラメータを選択する必要がある。
ここで開発者は次のような疑問を持つかもしれない：
平文空間はどのくらい必要か？ 暗号文の大きさはどれくらいまで許容できるか？ どこで並列計算ができるか？ など……
さらに、FHEは任意の計算をサポートできるが、FHEプログラムを書く際には開発者の思考法を変える必要がある。例えば、変数に基づいて分岐（if-else）を記述することはできない。なぜなら、変数を普通のデータとして直接比較できないからである。代わりに、すべての分岐条件を含むような計算にコードを書き換える必要がある。これと同じ理由で、ループもコード中に記述できない。
要するに、FHEに慣れていない開発者にとって、自分のアプリケーションにFHEを統合することはほぼ不可能である。FHEが提示する複雑さを抽象化するための顕著な開発ツールとインフラストラクチャーが必要となる。
解決策：
1. Web3向けFHEコンパイラー
グーグルやマイクロソフトなどの企業によって構築されたFHEコンパイラーは存在するが、これらは：
・パフォーマンスを設計目標にしておらず、直接回路を書くのに比べて1000倍の「オーバーヘッド」が発生する
・CKKS（すなわちML）向けに最適化されており、DeFiに必要なBFV/BGVにはあまり役立たない
・Web3向けに構築されていない。ZKPスキームやプログラマブルブロックチェーンとの互換性をサポートしていない
Sunscreen FHEコンパイラーの登場までは、このような状況だった。これはWeb3ネイティブのコンパイラーであり、ハードウェアアクセラレーターなしでも算術演算（例：DeFi）に対して最良のパフォーマンスを提供する。前述したように、パラメータ選択はFHEスキームを実装する上で最も困難な部分の一つである。Sunscreenはパラメータ選択を自動化するだけでなく、データ符号化、鍵選択、再線形化とモジュラス切替の実装、回路設定、SIMD操作の実現までを行う。
技術の進歩とともに、Sunscreenコンパイラーだけでなく、他のチームも独自の、より高度な言語をサポートするさらなる最適化を施したコンパイラーを構築することを期待している。
2. 新しいFHEライブラリー
研究者たちが新しい効率的なスキームを探求し続けている一方で、FHEライブラリーはより多くの開発者がFHEを統合できるようにする。
FHEスマートコントラクトを例に挙げよう。さまざまなFHEライブラリーから選ぶのは難しいが、オンチェーンFHEについて話すとき、選択肢はWeb3では少数の支配的なプログラミング言語しかないため、容易になる。
例えば、ZamaのfhEVMは、ZamaのオープンソースライブラリーTFHE-rsを典型的なEVMに統合し、準同型演算をプリコンパイル契約として公開している。これにより、開発者はコンパイラツールを変更することなく、自身のコントラクトで暗号化データを使用できるようになる。
他の特定のシナリオでは、さらに別のインフラが必要になるかもしれない。例えば、C++で書かれたTFHEライブラリーはRust版ほどメンテナンスされていない。TFHE-rsはC/C++のエクスポートをサポートしているが、C++開発者がより良い互換性とパフォーマンスを求める場合、独自のTFHEライブラリーバージョンを書く必要がある。
最後に、FHEインフラが市場に不足している根本的な理由の一つは、FHE-RAMを効果的に構築する方法がまだ存在しないことにある。一つの解決方向としては、特定のオペコードを持たないFHE-EVMに関する研究が考えられる。
セキュアなしきい値復号（Secure Threshold Decryption）
課題：不安定／中央集権的なしきい値復号
すべての秘密を保持する共有状態システムは、暗号化と復号鍵に基づいている。いかなる単一の当事者も信頼できないため、復号鍵はネットワーク参加者間でマルチパーティ計算（MPC）によって分割される。
オンチェーン完全準同型暗号（FHE）において最も挑戦的な側面の一つは、安全かつ高性能なしきい値復号プロトコルを構築することである。主に二つのボトルネックがある：
（1）FHEベースの計算は顕著な「オーバーヘッド」を導入するため、高性能なノードが必要となり、結果的に検証者セットの潜在的な規模が小さくなる；
（2）復号プロトコルに参加するノード数が増えると、遅延も増加する。
少なくとも現時点では、FHEプロトコルは検証者の大多数が誠実であることを前提としているが、上述のようにオンチェーンFHEは小さな検証者セットを意味するため、共謀や悪意ある行為のリスクが高まる。
もししきい値ノードが共謀して悪意を持ったらどうなるか？ 彼らはプロトコルを迂回し、基本的に何でも、ユーザーがオンチェーンに入力したあらゆるデータを復号できるようになる。さらに注意すべきは、現在のシステムでは復号プロトコルが気づかれずに発生する可能性がある（いわゆる「サイレント攻撃」）点である。
解決策：改良されたしきい値復号または動的MPC
しきい値復号の欠点を解決するためのいくつかの方法がある。
（1）n/2しきい値を有効にすることで、共謀をより困難にする；
（2）ハードウェアセキュリティモジュール（HSM）内でしきい値復号プロトコルを実行する；
（3）信頼できる実行環境（TEE）に基づくしきい値復号ネットワークを使用し、分散型チェーンが認証を管理し、動的な鍵管理を可能にする。
しきい値復号を利用することよりも、MPCを使う方が現実的だろう。オンチェーンFHEで使用可能なMPCプロトコルの画期的な例として、Odsyの新しい2PC-MPCがある。これは初めての非共謀かつ大規模に分散化されたMPCアルゴリズムである。
もう一つの方法として、データをユーザーの公開鍵のみで暗号化するという方法がある。その後、検証者が準同型演算を行い、必要に応じてユーザー自身が結果を復号する。これは特定のユースケースにしか適用できないが、しきい値の仮定を完全に回避できる。
まとめると、オンチェーンFHEには以下のような特徴を持つ効率的なMPC実装が必要である：
（1）悪意のある行動者に対しても動作する；
（2）最小限の遅延を導入する；
（3）無許可／柔軟なノード参加を可能にする。
ユーザー入力と計算当事者のためのゼロ知識証明（ZKP）
課題：ユーザー入力と計算の検証可能性
Web2の世界では、計算タスクを実行するよう依頼すると、裏で企業が約束通りにそれを実行すると完全に信用する。Web3では、このモデルは完全に逆転する。企業の評判に依存して彼らが誠実に行動すると単純に信じるのではなく、信頼不要な環境で動作する。つまり、ユーザーは誰も信用する必要がない。
完全準同型暗号（FHE）は暗号化されたデータを処理できるが、ユーザー入力や計算の正しさを検証することはできない。検証能力がなければ、ブロックチェーンの文脈においてFHEはほとんど役に立たない。
解決策：ユーザー入力と計算当事者のためのZKP
FHEは誰でも暗号化データ上で任意の計算を行えるようにするが、ZKPは基盤情報自体を明かすことなく何かが真であることを証明できる。では、これらはどう関係しているのか？
FHEとZKPは三つの重要な方法で組み合わされる：
1. ユーザーは、自分の入力暗号文が正しい形式であることを示す証明を提出する必要がある。つまり、暗号文が暗号スキームの要件を満たしており、単なる任意のデータ文字列ではないということ。
2. ユーザーは、自分の入力平文が特定アプリケーションの条件を満たしていることを証明する必要がある。例えば、口座残高が送金額より大きいこと。
3. 検証ノード（すなわち計算当事者）は、FHE計算を正しく実行したことを証明する必要がある。これは「検証可能なFHE」と呼ばれ、ロールアップに必要なZKPに類似している。
ZKPの応用をさらに探るために：
1. 暗号文のZKP
FHEは格子ベース（lattice-based）の暗号理論に基づいている。つまり、暗号プリミティブの構成には格子（lattice）が関与しており、これらは耐量子（post-quantum）セキュアである。一方、SNARKs、STARKs、Bulletproofsといった一般的なZKPは、格子ベースの暗号理論に依存していない。
ユーザーのFHE暗号文が正しい形式であることを証明するには、それが環の要素を持つ行列-ベクトル方程式を満たし、かつその要素の数値が小さいことを示す必要がある。本質的に、格子ベースの関係（lattice-based relations）を処理するために設計され、オンチェーンでの検証コスト効率が高い証明システムが必要とされるが、これは未解決の研究分野である。
2. 平文入力のZKP
正しい形式の暗号文を証明するだけでなく、ユーザーは自分の入力平文がアプリケーションの要件を満たしていることも証明する必要がある。幸運なことに、前のステップとは異なり、ユーザー入力の有効性を証明するために一般的なSNARKsを利用できるため、開発者は既存のZKPスキーム、ライブラリー、インフラを活用できる。
しかし、課題はこれらの二つの証明システムを「接続」する必要がある点にある。「接続」とは、ユーザーが両方の証明システムで同じ入力を使っていることを保証することを意味する。そうでなければ、悪意あるユーザーがプロトコルを騙す可能性がある。繰り返すが、これは極めて困難な暗号的達成であり、初期段階の研究分野でもある。
Sunscreenはすでに基礎を築いており、そのZKPコンパイラーはSDLPと最も簡単に接続できるBulletproofsをサポートしている。FHEとZKPコンパイラーを「接続」するための研究も継続的に進められている。
Mind Networkは、FHEによる安全な計算と同時に、ゼロトラストの入出力を確保するためにZKPの統合を主導してきた。
3. 正しい計算のZKP
既存のハードウェア上で動作するFHEは極めて非効率的で高価である。先に見たスケーラビリティの三難問題の動的な表現として、ノードリソース要求が高いネットワークは十分な分散化レベルまで拡張できない。一つの解決策として「検証可能なFHE」と呼ばれるプロセスがあり、ここで計算当事者（検証者）は取引が誠実に実行されたことを証明するZKPを提出する。
検証可能なFHEの初期プロトタイプは、SherLOCKEDというプロジェクトによって示されている。本質的に、FHE計算はRisc ZEROのBonsai zkVMに読み込まれ、zkVMがオフチェーンで暗号化データ上の計算を処理し、ZKP付きの結果を返してオンチェーンで状態を更新する。
FHEコプロセッサーを利用した最近の事例として、Aztecのオンチェーンオークションデモがある。前述したように、既存のFHEチェーンはしきい値鍵を使って全体状態を暗号化しており、システムの強度はしきい値委員会（threshold committee）に依存している。一方、Aztecではユーザーが自身のデータを所有しているため、しきい値のセキュリティ仮定に縛られない。
最後に、開発者がまずどこでFHEアプリケーションを構築できるかを理解することが重要である。開発者はFHE対応L1、FHEロールアップ、または任意のEVMチェーン上でアプリケーションを構築し、FHEコプロセッサーを利用することができる。各設計にはそれぞれトレードオフがあるが、我々はFhenixが開拓したように、設計の整ったFHEロールアップやFHEコプロセッサーを好む。なぜなら、これらはイーサリアムからセキュリティなどの他の利点を継承できるからである。
つい最近まで、FHE暗号化データ上で詐欺証明を実現することは複雑だったが、最近Fhenix.ioのチームは、Arbitrum NitroスタックとFHEロジックをWebAssemblyにコンパイルすることで詐欺証明を実現する方法を示した。
FHEのデータ可用性（DA）レイヤー
課題：カスタマイズ性とスループットの欠如
Web2では「ストレージ」は商品化されているが、Web3ではそうではない。完全準同型暗号（FHE）は1万倍以上のデータ膨張を維持していることを考慮すると、大量のFHE暗号文をどこに保存するかを決定する必要がある。特定のDAレイヤー内のすべてのノードオペレーターがすべてのFHEチェーンのデータをダウンロードして保存する必要がある場合、機関オペレーターだけが需要に追いつけるため、中央集権化のリスクが高まる。
スループットに関しては、Celestiaの最高速度は6.7MB/sであるが、FHEMLを実行したい場合、毎秒数GBの帯域幅が必要になる。1k(x)が最近共有したデータによると、設計上の意思決定がスループットを制限している（意図的）ため、既存のDAレイヤーはFHEをサポートできない。
解決策：水平スケーリング＋カスタマイズ性
水平スケーラビリティをサポートできるDAレイヤーが必要である。既存のDAアーキテクチャはすべてのデータをネットワーク内のすべてのノードに配布するため、これがスケーラビリティの主な制限となっている。一方、水平スケーラビリティとは、より多くのDAノードがシステムに参加するにつれて、各ノードが保存するデータ量が減少し、利用可能なブロックスペースが増えることでパフォーマンスとコストが改善されることを意味する。
また、FHEに関連する大量データのサイズを考慮すると、開発者に高度な消散符号化しきい値（erasure coding thresholds）のカスタマイズを提供することは理にかなっている。言い換えれば、開発者はDAシステムに対してどのような保証に満足しているか？ それはステークに基づく重み付けか、それとも分散化に基づく重み付けか。
EigenDAのアーキテクチャは、FHEのDAレイヤーとしての可能性の一つの基盤になり得る。その水平スケーラビリティ、構造的成本の削減、DAとコンセンサスの分離などの特性は、FHEをサポートできるスケーラビリティレベルの道を切り開く。
最後に、より高次のアイデアとして、暗号文の最適化されたストレージスロットを構築する可能性がある。暗号文は特定の符号化スキームに従うため、最適化されたストレージスロットを持つことで、ストレージ空間の効率的な利用と高速な取得が可能になるかもしれない。
完全準同型暗号（FHE）ハードウェア
課題：低パフォーマンスの完全準同型暗号（FHE）ハードウェア
オンチェーン完全準同型暗号（FHE）アプリケーションの普及において、主要な問題は計算オーバーヘッドによる顕著な遅延であり、標準的な処理ハードウェア上でFHEを実行するのは非現実的である。この制限は、プロセッサーが巨大なデータ量を処理する必要があるため、メモリとの大量なやり取りに起因する。メモリとのやり取りに加えて、複雑な多項式計算や時間のかかる暗号文維持操作も大きなオーバーヘッドをもたらす。
FHEアクセラレーターの現状を深く理解するには、その具体的な設計を明らかにする必要がある：特定用途向けFHEアクセラレーターと汎用FHEアクセラレーター。
FHEの計算複雑性とハードウェア設計の核心は、与えられたアプリケーションに必要な乗算の数、すなわち「準同型操作の深さ」に関係している。特定用途の場合、深さは既知であり、システムパラメータと関連する計算は固定される。したがって、特定用途向けハードウェア設計はより簡単になり、通常、汎用アクセラレーター設計よりも優れたパフォーマンスに最適化できる。一般に、FHEが任意の数の乗算をサポートする必要がある場合、準同型操作中に蓄積されるノイズを取り除くためにブートストラップ技術を導入する必要がある。ブートストラップ技術はコストが高く、チップメモリ、メモリ帯域幅、計算など大量のハードウェアリソースを必要とするため、ハードウェア設計は特定用途向けとは大きく異なる。そのため、インテル、Duality、SRI、DARPAといった業界の主要プレイヤーがGPUやASIC設計において行った作業は、上限を引き上げる上で確かに貢献しているが、ブロックチェーンシナリオを直接サポートするものではない可能性がある。
開発コストに関しては、汎用ハードウェアは特定用途向けよりも設計・製造に多くの資本を必要とするが、その柔軟性により、より広範な用途で使用できる。一方、特定用途向け設計では、アプリケーションのニーズが変化し、より深い準同型計算をサポートする必要がある場合、特定用途ハードウェアと一部のソフトウェア技術（MPCなど）を組み合わせて、汎用ハードウェアと同じ目的を達成する必要がある。
注目すべきは、FHEMLなどの特定用途ケースに比べて、オンチェーンFHEのアクセラレーションははるかに困難である点だ。なぜなら、より一般的な計算を処理できる必要があり、より限定された集合ではないからである。例えば、現在のfhEVM開発ネットワークのトランザクション処理速度は、一桁TPSに制限されている。
ブロックチェーンに特化したFHEアクセラレーターが必要であることを踏まえると、もう一つの考慮点は：ZKPハードウェアからFHEハードウェアへの移行性がどの程度あるかである。
ZKPとFHEの間にはいくつか共通のモジュールがある。例えば、数論変換（NTT）や基礎的な多項式操作など。しかし、これら二つのケースで使用されるNTTのビット幅（bit width）は異なる。ZKPでは、ハードウェアが64ビットや256ビットなど複数のビット幅のNTTをサポートする必要があるが、FHEでは剰余数系を使用するため、NTTのオペランドが短くなる。第二に、ZKPで処理されるNTTの次数は通常FHEより高い。この二つの理由から、ZKPとFHEの両方に対して開発者が満足する性能を持つNTTモジュールを設計するのは容易ではない。NTT以外にも、自己同型（automorphism）など、ZKPには存在せずFHEにのみ存在する計算ボトルネックがある。ZKPハードウェアを単純にFHE設定に転用する一つの方法は、NTT計算タスクをZKPハードウェアに割り当て、CPUや他のハードウェアでFHEの残りの計算を処理することである。
これらの課題を総括すると、暗号化データ上でFHEを使用して計算を行うことはかつて平文データ上で行うのに比べて10万倍遅かった。しかし、新しい暗号スキームやFHEハードウェアの最新の発展により、現在のパフォーマンスは平文データに比べて約100倍遅いまで大幅に改善されている。
解決策：
1. FHEハードウェアの改善
多くのチームが積極的にFHEアクセラレーターを構築しているが、汎用ブロックチェーン計算（例：TFHE）に特化したFHEアクセラレーターに焦点を当てていない。ブロックチェーン向けの特定ハードウェアアクセラレーターの例として、FPT（固定小数点FPGAアクセラレーター）がある。FPTはFHE計算に内在するノイズを大きく活用する初のハードウェアアクセラレーターであり、TFHEブートストラップを完全に近似的な固定小数点演算で実現している。FHEに有用な可能性のある別のプロジェクトはBASALISCであり、クラウド上でFHE計算を大幅に高速化することを目指したハードウェアアクセラレーターアーキテクチャシリーズである。
前述したように、FHEハードウェア設計における主要なボトルネックの一つは、メモリとの大量なやり取りである。この障壁を回避する潜在的な解決策は、メモリとのやり取りを可能な限り減らすことである。プロセッサーメモリ（PIM）またはニアメモリコンピューティング（near memory computation）がこの状況で役立つかもしれない。PIMは将来のコンピューターシステムにおける「メモリウォール（memory wall）」の課題に対処する有望な解決策であり、メモリに計算とストレージの両方の機能を持たせることで、計算とメモリの関係に根本的な改革を約束する。過去10年間で、抵抗RAM、スピン転送トルク磁気RAM、フェーズチェンジメモリなど、この問題を解決する非揮発性メモリの設計において大きな進展があった。このような特殊メモリを使用することで、機械学習や格子ベースの公開鍵暗号において計算性能が著しく改善されたことが研究で示されている。
2. 最適化されたソフトウェアとハードウェア
最近の発展の中で、ソフトウェアはハードウェアアクセラレーションプロセスの重要な構成要素として認識されている。有名なFHEアクセラレーターであるF1やCraterLakeは、コンパイラを使用したハイブリッドなソフトウェア・ハードウェア共同設計を採用している。
この分野の発展とともに、ブロックチェーン向けFHEコンパイラーと共同設計された完全な機能を持つコンパイラーが登場すると期待される。FHEコンパイラーは、対応するFHEスキームのコストモデルに基づいてFHEプログラムを最適化できる。これらのFHEコンパイラーはFHEアクセラレーターのコンパイラーと統合され、ハードウェアレベルのコストモデルを組み合わせることで、エンドツーエンドのパフォーマンスを向上させることができる。
3. ネットワークFHEアクセラレーター：垂直スケーリングから水平スケーリングへ
既存のFHEハードウェアアクセラレーションへの取り組みは主に「垂直スケーリング」、つまり単一アクセラレーターの垂直的改善に集中している。一方、「水平スケーリング」は複数のFHEアクセラレーターをネットワークで横方向に接続することに焦点を当てており、これはゼロ知識証明（ZKPs）の並列証明生成と同様に、パフォーマンスを大幅に向上させる可能性がある。
FHEアクセラレーションの主要な困難の一つはデータ膨張問題である。つまり、暗号化と計算の過程でデータサイズが著しく増加し、チップ内およびチップ外のメモリ間での効率的なデータ転送に課題をもたらす。
データ膨張は、複数のFHEアクセラレーターをネットワークで横方向に接続する際に大きな課題をもたらす。したがって、FHEハードウェアとネットワークの共同設計は、将来の研究において有望な方向性となるだろう。例えば、FHEアクセラレーター向けの適応型ネットワークリング：リアルタイムの計算負荷とネットワークトラフィックに基づき、FHEアクセラレーター間のデータパスを動的に調整するルーティング機構を実現する。これにより、最適なデータ転送速度と効率的なリソース利用が保証される。
おわりに
FHEは、さまざまなプラットフォーム上でデータを保護する方法を根本的に再構築し、前例のないプライバシーの新時代の道を切り開くだろう。このようなシステムを構築するには、FHE、ゼロ知識証明（ZKPs）、マルチパーティ計算（MPC）における重大な進展が必要となる。
この新たな領域に進む中で、暗号学者、ソフトウェアエンジニア、ハードウェア専門家間の協力が不可欠となる。立法者、規制当局なども言うまでもなく、コンプライアンスが主流採用への唯一の道だからである。
結局のところ、FHEはデジタル主権の変革の波頭に立ち、データプライバシーとセキュリティが相互に排他的ではなく密接に結びつく未来を予告する。
特別謝辞
Mason Song（Mind Network）、Guy Itzhaki（Fhenix）、Leo Fan（Cysic）、Kurt Pan、Xiang Xie（PADO）、Nitanshu Lokhande（BananaHQ）によるレビューに深く感謝します。読者の皆様には、これらの人物がこの分野で行ってきた印象的な仕事と努力をぜひご確認いただきたいと思います！
TechFlow公式コミュニティへようこそ
Telegram購読グループ：https://t.me/TechFlowDaily
Twitter公式アカウント：https://x.com/TechFlowPost
Twitter英語アカウント：https://x.com/BlockFlow_News
