)

核となるアイデア:

1. FHEは「暗号化の聖杯」になることを約束していますが、現在の採用を制限する多くのパフォーマンス、開発者の経験、およびセキュリティ上の懸念があります。

2. 上の図に示されているように、FHEをZKPやMPCと一緒に使用して、真に機密で安全な共有状態システムを構築する必要があります。

3.FHEは急速に進化しています。新しいコンパイラ、ライブラリ、ハードウェアなどの開発 言うまでもなく、FHEはWeb2企業(Intel、Google、DARPAなど)の研究開発から多大な恩恵を受けています。

FHEとその周辺のエコシステムが成熟 4.As、「検証可能なFHE」が標準になることを期待しています。 FHEアプリケーションは、計算と検証をFHEコプロセッサにアウトソーシングすることを選択できます。

5.オンチェーンFHEの根本的な制限は、「復号化キーは誰が持っているか」です。閾値復号化とMPCは解決策を提供しますが、一般的にはパフォーマンスとセキュリティのトレードオフに縛られます。

はじめに:

ブロックチェーンの透明性は諸刃の剣です。そのオープン性と可観測性には美しさがありますが、企業での導入には根本的な障害となっています。

オンチェーンのプライバシーは、10年近くにわたり、暗号資産における最も困難な問題の1つでした。 オンチェーンプライバシーを実現するためにZKベースのシステムを構築しているチームはたくさんありますが。共有された暗号化された状態はサポートできません。 なぜでしょうか。簡単に言うと、これらのプログラムは一連のZKPの関数であり、現在の状態に任意のロジックを適用することは不可能だからです。 これはどういう意味ですか? 基本的に、ZKPだけでは機密の共有ステートアプリケーション(プライベートUniswapを思い浮かべてください)を構築することはできません。

しかし、最近のブレークスルーにより、ZKPと完全準同型暗号(FHE)を組み合わせることで、完全に一般化可能で機密性の高いDeFiを実現できることが示されています。 どう。FHEは、暗号化されたデータに対して任意の計算を可能にする、急成長している暗号分野です(クレイジーに聞こえますよね?!上の図に示すように、ZKPはユーザー入力と計算の完全性を証明でき、FHEは計算自体を処理できます。

FHEは「暗号学の聖杯」であることを約束しますが、この分野とそのさまざまな課題と可能な解決策の客観的な分析を提供するよう努めています。 以下のオンチェーンFHEのトピックを取り上げます。

• FHEスキーム、ライブラリ、コンパイラ
• セキュアしきい値復号化
• ユーザー入力+コンピューティングパーティのZKP
• プログラマブルでスケーラブルなDAレイヤー
• FHEハードウェア

FHEスキーム、ライブラリ、コンパイラ

課題:初期段階のFHEスキーム、ライブラリ、コンパイラ

オンチェーンFHEの根本的なボトルネックは、遅れている開発者ツール/インフラにあります。 ZKPやMPCとは異なり、FHEは2009年から存在しているため、成熟までのタイムラインははるかに短くなっています。

FHE DevExの主な制限は次のとおりです。

• 開発者がバックエンドの暗号化に関する知識があまりなくてもコーディングできる使いやすいフロントエンド言語
• すべての汚い作業を処理できる完全に機能する FHE コンパイラ。 (パラメータ選択、BGV/BFVのSIMD最適化、並列最適化)
• 既存のFHEスキーム(特にTFHE)は、通常の計算と比較して約1000倍遅くなります

FHE の統合の複雑さを真に理解するために、開発者のジャーニーを順を追って見ていきましょう。

FHEをアプリケーションに統合するための最初のステップは、使用するFHEスキームを選択することです。 次の表では、主要なスキームについて説明します。

上の表に示されているように、FHEW や TFHE のようなブール回路は、ブートストラップが最も速く、かなり複雑なパラメータ選択手順を複雑にすることを避けることができ、任意/一般的な計算に使用できますが、比較的遅いです。BGV/BFVは高精度の算術計算が効率的であるため、一般的なDeFiに適している可能性がありますが、開発者はスキームのすべてのパラメータを設定するために、事前に回路の深さを知る必要があります。 一方、CKKSは精度誤差が許容される準同型乗算をサポートしているため、MLなどの不正確なユースケースに最適です。

開発者は、FHEソリューションが他のすべての設計上の決定と将来のパフォーマンスに影響を与えるため、非常に慎重に選択する必要があります。 さらに、モジュールサイズの選択や多項式次数の役割など、FHEスキームを正しく設定するために重要ないくつかの重要なパラメータがあります。

ライブラリに移ると、一般的なFHEライブラリの特徴と機能は、以下の表から確認できます。

しかし、ライブラリは、以下に示すように、スキームやコンパイラとのさまざまな関係も持っています。

FHEソリューションを選択した後、開発者はパラメータを設定する必要があります。 パラメータの適切な選択は、FHEスキームのパフォーマンスに大きな影響を与えます。 さらに難しいのは、抽象代数、再接近化やアナログ-デジタル切り替えなどのFHE固有の演算、算術回路やバイナリ回路をある程度理解する必要があることです。 最後に、パラメータを効果的に選択するには、それらがFHEスキームにどのように影響するかを概念的に理解する必要があります。

この時点で、開発者は次のような疑問を抱くかもしれません。

プレーンテキストスペースはどのくらいの大きさにする必要がありますか? 許容される暗号文の大きさはどれくらいですか? 計算を並列化できる場所 などなど...

また、FHEは任意の計算にも対応できますが、FHEプログラムを書く際には考え方を変える必要があります。 たとえば、プログラムはプレーンデータのように変数を直接比較できないため、プログラム内の変数に応じて分岐(if-else)を書くことはできません。 代わりに、開発者はコードを分岐から、すべての分岐の条件を組み込むことができる何らかの計算に変更する必要があります。 同様に、これにより、開発者はコードにループを記述できなくなります。

つまり、FHE に不慣れな開発者にとって、FHE をアプリケーションに統合することはほぼ不可能です。 FHEがもたらす複雑さを抽象化するために、かなりの開発ツール/インフラが必要になります。

解決：

1. Web3 固有の FHE コンパイラ

GoogleやMicrosoftなどによって構築されたFHEコンパイラはすでに存在しますが、それらは次のとおりです。

• パフォーマンスを念頭に置いて設計されておらず、回路を直接書く場合と比較して1000倍のオーバーヘッドを追加します
• CKKS(別名ML)に最適化されており、DeFiに必要なBFV/BGVには適していません。
• Web3 用に構築されていません。 ZKPスキーム、プログラムチェーンなどとの互換性はサポートしていません。

それは日焼け止めFHEコンパイラまでです。 これはWeb3ネイティブコンパイラであり、ハードウェアアクセラレータなしで算術演算(DeFiなど)で最高のパフォーマンスを提供します。 前述したように、パラメータの選択は、FHEスキームを実装する上で最も難しい部分であることは間違いありません。日焼け止めは、パラメータ選択だけでなく、データエンコーディング、キー選択、再線形化とモジュラススイッチングの実装、回路のセットアップ、SIMDスタイルの操作の実装を備えています。

将来的には、Sunscreenコンパイラだけでなく、他のチームが他の高級言語をサポートする独自の実装を構築することで、さらなる最適化が行われることを期待しています。

1. 新しいFHEライブラリ

研究者が新しい強力なスキームを模索し続ける一方で、FHEライブラリはより多くの開発者がFHEを統合できるようにすることができます。

FHEスマートコントラクトを例にとってみましょう。 異なるFHEライブラリから選択するのは難しいかもしれませんが、Web3全体で支配的なプログラミング言語はごくわずかであるため、オンチェーンFHEについて話すとより簡単になります。

たとえば、Zama の fhEVM は、Zama のオープンソース ライブラリである TFHE-rs を一般的な EVM に統合し、準同型演算をプリコンパイルされたコントラクトとして公開します。 開発者がコンパイルツールを変更することなく、コントラクトで暗号化されたデータを効果的に使用できるようにします。

その他の特定のシナリオでは、他のインフラストラクチャが必要になる場合があります。 たとえば、C++ で記述された TFHE ライブラリは、Rust バージョンほどよく維持されていません。 TFHE-rs は C/C++ のエクスポートをサポートできますが、C++ 開発者が互換性とパフォーマンスを向上させたい場合は、独自のバージョンの TFHE ライブラリを作成する必要があります。

最後に、市場にFHEインフラストラクチャが不足している主な理由は、FHE-RAMを構築するための効率的な方法がないことです。 考えられる解決策の 1 つは、特定のオペコードなしで FHE-EVM で作業することです。

セキュアしきい値復号化

課題:安全でない/集中型のしきい値復号化

すべての機密共有状態システムは、暗号化/復号化キーを前提としています。 単一のパーティは信頼できないため、復号化キーはネットワーク参加者間でシャード化されます。

オンチェーン FHE(Threshold FHE)の最も困難な側面の 1 つは、安全で優れたしきい値復号プロトコルを構築することです。 主なボトルネックは2つあります:(1)FHEベースの計算は大きなオーバーヘッドをもたらし、その結果、本質的にバリデータセットの潜在的なサイズを縮小する高性能なノードが必要になります(2)復号プロトコルに参加するノードの数が増えると、レイテンシーが増加します。

少なくとも今のところ、FHEプロトコルはバリデーターの誠実な過半数に依存していますが、上記のように、しきい値FHEはバリデーターセットが小さいため、共謀や悪意のある行動の可能性が高くなることを意味します。

閾値ノードが共謀した場合はどうなりますか? プロトコルをバイパスし、ユーザー入力からオンチェーンデータまで、基本的に何でも復号化することができます。 さらに、復号化プロトコルは、現在のシステムでは検出されずに発生する可能性があることに注意することが重要です(別名「サイレント攻撃」)。

ソリューション:閾値復号化または動的MPCの改善

しきい値復号化の欠点に対処する方法はいくつかあります。 (1) 共謀をより困難にする n/2 しきい値を有効にする (2) HSM 内でしきい値復号プロトコルを実行する (3) 認証に分散型チェーンによって制御される TEE ベースのしきい値復号ネットワークを使用して、動的な鍵管理を可能にします。

しきい値復号化を利用するのではなく、代わりにMPCを使用できます。 オンチェーンFHEで使用できるMPCプロトコルの例には、最初の非共謀的で大規模に分散化されたMPCアルゴリズムであるOdsyの新しい2PC-MPCが含まれます。

別のアプローチとして、ユーザーの公開キーのみを使用してデータを暗号化する方法があります。 その後、バリデーターは準同型演算を処理し、ユーザー自身が必要に応じて結果を復号化できます。 ニッチなユースケースでのみ実現可能ですが、しきい値の仮定を完全に回避することもできます。

要約すると、オンチェーンFHEには、(1)悪意のあるアクターがいる場合でも機能し、(2)レイテンシーが最小限に抑えられる、(3)ノードのパーミッションレス/柔軟なエントリを可能にする、効率的なMPC実装が必要です。

ゼロ知識証明(ZKP) ユーザー入力とコンピューティングパーティ向け

課題:ユーザー入力の検証可能性 + 計算:

web2では、計算タスクの実行を依頼すると、特定の企業が舞台裏で約束したとおりにタスクを実行することを完全に信頼しています。 web3では、モデルは完全に反転します。企業の評判に頼り、誠実に行動してくれると信じるのではなく、トラストレスな環境で運営されているので、ユーザーは誰も信用する必要はないはずです。

FHEは暗号化されたデータの処理を可能にしますが、ユーザー入力や計算の正確性を検証することはできません。 どちらかをチェックする機能がなければ、FHEはブロックチェーンのコンテキストではほとんど役に立ちません。

ソリューション:ユーザー入力+コンピューティングパーティのZKP:

FHEでは、暗号化されたデータに対して誰でも任意の計算を行うことができますが、ZKPでは、基礎となる情報自体を明らかにすることなく、何かが真実であることを証明できます。 では、それらはどのように関連しているのでしょうか?

FHEとZKPを組み合わせるには、次の3つの主要な方法があります。

1. ユーザーは、入力された暗号文が整形式であることの証明を提出する必要があります。 つまり、暗号文は暗号化方式の要件を満たしており、単なる任意のデータ文字列ではありません。
2. ユーザーは、入力されたプレーンテキストが特定のアプリケーションの条件を満たしていることを証明する必要があります。 例amount_balance > amount_transfer
3. バリデーターノード(別名コンピューティングパーティ)は、FHE計算を正しく実行したことを証明する必要があります。 これは「検証可能な FHE」と呼ばれ、ロールアップに必要な ZKP に類似していると見なすことができます。

ZKPの用途をさらに詳しく調べるには:

1. 暗号文のZKP

FHEは格子ベースの暗号に基づいて構築されているため、暗号プリミティブの構築には、PQ(ポスト量子)で安全な格子が含まれます。 対照的に、SNARKS、STARKS、Bulletproofsなどの一般的なZKPは、格子ベースの暗号に依存していません。

ユーザの FHE 暗号文が整形式であることを証明するには、それが環からのエントリを持つ行列ベクトル方程式を満たすこと、およびこれらの要素の数値が小さいことを示す必要があります。 基本的には、オープンな研究領域である格子ベースの関係を扱うために設計された、費用対効果の高いオンチェーン検証証明システムが必要です。

1. プレーンテキスト入力のZKP

ユーザーは、整形式の暗号文を証明することに加えて、入力された平文がアプリケーションの要件を満たしていることを証明する必要があります。 幸いなことに、前のステップとは異なり、一般的なSNARKを利用してユーザー入力の有効性を証明できるため、開発者は既存のZKPスキーム、ライブラリ、およびインフラストラクチャを利用できます。

しかし、難しいのは、2つの証明システムを「接続」する必要があることです。 接続は、ユーザーが両方のプルーフシステムに同じ入力を使用したことを確認する必要があります。そうしないと、悪意のあるユーザーがプロトコルをだます可能性があります。 繰り返しになりますが、これは非常に困難な暗号の偉業であり、初期の研究のオープンな領域です。

Sunscreenは、SDLPと最も簡単に接続できるため、BulletproofsをサポートするZKPコンパイラの基礎も築きました。 今後、FHEとZKPコンパイラを「リンク」するための開発が行われています。

Mind Networkは、ZKPの統合を先駆的に行い、ゼロトラストのインプットとアウトプットを確保し、FHEを活用して安全な計算を実現しています。

1. 正しい計算のZKP

既存のハードウェアでFHEを実行することは、非常に非効率的でコストがかかります。 スケーラビリティのトリレンマのダイナミクスが以前に展開されたように、ノードリソースの要件が高いネットワークは、十分なレベルの分散化に拡張できません。 考えられる解決策は、「検証可能なFHE」と呼ばれるプロセスであり、コンピューティング当事者(バリデーター)がZKPを提出してトランザクションの誠実な実行を証明するプロセスです。

検証可能なFHEの初期のプロトタイプは、SherLOCKEDと呼ばれるプロジェクトによって表示できます。 基本的に、FHE 計算は Risc ZERO の Bonsai にオフロードされ、暗号化されたデータの計算をオフチェーンで処理し、結果を ZKP で返し、オンチェーンの状態を更新します。

FHEコプロセッサを活用した最近の例は、Aztecのオンチェーンオークションデモで見ることができます。 前述したように、既存のFHEチェーンは州全体を閾値キーで暗号化するため、システムの強度は閾値委員会と同程度です。 逆に、Aztec では、ユーザーは独自のデータを所有するため、しきい値のセキュリティの前提の対象にはなりません。

最後に、開発者が FHE アプリケーションを最初に構築できる場所について触れておくことが重要です。 開発者は、FHE搭載のL1またはFHEロールアップのいずれかでアプリケーションを構築するか、任意のEVMチェーンで構築してFHEコプロセッサを活用できます。 各設計には独自のトレードオフがありますが、イーサリアムからセキュリティを継承するなどの利点があるため、適切に設計されたFHEロールアップ(Fhenixが開拓)またはFHEコプロセッサに傾倒しています。

最近まで、FHEで暗号化されたデータで不正防止を実現するのは複雑でしたが、最近、Fhenix.io のチームは、Arbitrum NitroスタックとFHEロジックのコンパイルを組み合わせてWebAssemblyに使用して、不正防止を実現する方法を実演しました。

FHEのデータ可用性(DA)レイヤー

課題:カスタマイズ性とスループットの欠如

Web2ではストレージがコモディティ化されていますが、Web3では同じことが当てはまりません。 FHEが10,000x+の大規模なデータブローアップを維持していることを考えると、大きなFHE暗号文をどこに保存するかを把握する必要があります。 特定のDAレイヤーのすべてのノードオペレーターがすべてのFHEチェーンのデータをダウンロードして保存した場合、機関投資家のオペレーターのみが需要に追いつくことができ、中央集権化のリスクがあります。

スループットに関しては、Celestiaは6.7mb/sが最高で、FHEMLを実行する場合は、簡単にn GBs+/secが必要になります。 1k(x)が共有した最近のデータによると、既存のDAレイヤーは、スループットを(意図的に)制限する設計上の決定により、FHEをサポートできません。

解決策:水平スケーリング+カスタマイズ性

水平方向のスケーラビリティをサポートできるDAレイヤーが必要です。 既存のDAアーキテクチャでは、すべてのデータがネットワーク内のすべてのノードに伝搬されますが、これはスケーラビリティの大きな制約となっています。 逆に、水平方向のスケーラビリティでは、より多くのDAノードがシステムに入ると、各ノードはデータの1/nを格納し、より多くのブロックスペースが使用可能になるにつれてパフォーマンスとコストが向上します。

これとは別に、FHEに関連するデータサイズが大きいことを考えると、イレイジャーコーディングの閾値に関して、開発者により高いレベルのカスタマイズ性を提供することは理にかなっています。 すなわち、 DAシステムのどの程度が保証に満足していますか? ステークベースの重み付けか、分散化ベースの重み付けか。

EigenDAのアーキテクチャは、FHEのDAレイヤーがどのように見えるかの基礎として機能します。 これは、水平スケーリング、構造コストの削減、DAとコンセンサスの分離などの特性です。これらはすべて、いつの日かFHEをサポートする可能性のあるレベルのスケーラビリティに取って代わられます。

最後に、暗号文は特定の符号化方式に従うため、FHE 暗号文を格納するために最適化されたストレージ スロットを構築することが大まかなアイデアであり、最適化されたストレージ スロットを持つことは、ストレージの効率的な使用とより高速な検索に役立つ可能性があります。

完全準同型暗号化 (FHE) ハードウェア

課題:低性能FHEハードウェア

オンチェーンの完全準同型暗号化(FHE)アプリケーションの推進において、計算のオーバーヘッドによる大幅な遅延が大きな問題となり、標準的な処理ハードウェア上でFHEを実行することは現実的ではありません。 この制限は、プロセッサが処理する必要がある膨大な量のデータによるメモリとの相互作用の量が多いことに起因します。 メモリの相互作用に加えて、複雑な多項式計算や時間のかかる暗号文のメンテナンス操作も多くのオーバーヘッドをもたらします。

FHEアクセラレータの状態をさらに理解するには、アプリケーション固有のFHEアクセラレータと一般化可能なFHEアクセラレータという設計空間を明らかにする必要があります。

FHEの計算量とハードウェア設計の核心は、常に「準同型演算の深さ」と呼ばれる、特定のアプリケーションに必要な乗算の数に関連しています。 アプリケーション固有のケースでは、深さがわかっているため、システムパラメータと関連する計算は固定されています。 したがって、このアプリケーション固有のケースのハードウェア設計は容易であり、通常は一般化可能なアクセラレータ設計よりも優れたパフォーマンスのために最適化できます。 一般的なケースでは、FHEが任意の数の乗算をサポートする必要があるため、準同型演算で蓄積されたノイズの一部を除去するためにブートストラップが必要です。 ブートストラップはコストがかかり、オンチップメモリ、メモリ帯域幅、計算など、かなりのハードウェアリソースを必要とするため、ハードウェア設計はアプリ固有の設計とは大きく異なります。 したがって、Intel、Duality、SRI、DARPAなど、この分野の主要なプレーヤーが行った作業は、GPUおよびASICベースの設計で限界を押し広げていることは間違いありませんが、ブロックチェーンのユースケースをサポートするために1対1で適用できるとは限りません。

開発コストについて:汎用化可能なハードウェアは、アプリケーション固有のハードウェアよりも設計と製造に多くの資本を必要としますが、その柔軟性により、ハードウェアをより幅広いアプリケーション範囲で使用できます。 一方、アプリ固有の設計では、アプリケーションのニーズが変化し、より深い準同型計算のサポートが必要な場合、アプリ固有のハードウェアをMPCなどのいくつかのソフトウェア手法と組み合わせて、一般化可能なハードウェアと同じ目的を達成する必要があります。

重要なのは、オンチェーンFHEは、アプリケーション固有のユースケース(例:.FHEML)は、よりニッチなセットに対して、より一般的な計算を処理する能力を必要とするためです。 たとえば、現時点では fhEVM devnet は 1 桁の TPS に制限されています。

ブロックチェーンに合わせたFHEアクセラレーターが必要であることを考えると、ZKPハードウェアからFHEハードウェアへの作業の移行可能性も考慮する必要があります。

ZKPとFHEの間には、数論変換(NTT)や基礎となる多項式演算など、いくつかの共通モジュールがあります。 ただし、この2つのケースで使用されるNTTのビット幅は異なります。 ZKPでは、64ビットや256ビットなど、NTTの幅広いビット幅に対応する必要がありますが、FHEでは、NTTのオペランドは残数システムで表されるため、短くなります。 第2に、ZKPで取り扱われるNTTの程度は、一般的にFHE事件よりも高い。 この2つの理由から、ZKPとFHEの両方で満足のいく性能を実現するNTTのモジュールを設計することは容易ではありません。 NTT以外にも、ZKPにはない自己同型など、FHEの計算上のボトルネックがいくつかあります。 ZKP ハードウェアを FHE 設定に転送する単純な方法は、NTT コンピューティング タスクを ZKP ハードウェアにオフロードし、CPU またはその他のハードウェアを使用して FHE の残りの計算を処理することです。

課題の締めくくりとして、FHEを使用した暗号化されたデータの計算は、以前はプレーンテキストデータよりも100,000倍遅くなっていました。 しかし、新しい暗号化方式とFHEハードウェアの最近の開発により、現在のパフォーマンスは劇的に改善され、プレーンテキストデータよりも約100倍遅くなっています。

ソリューション：

1. FHEハードウェアの改善

FHEアクセラレーターを積極的に構築しているチームは数多くありますが、一般化可能なブロックチェーンコンピューティングに特化したFHEアクセラレーター(つまり、 TFHE)です。 ブロックチェーン固有のハードウェアアクセラレータの例としては、固定小数点FPGAアクセラレータであるFPTがあります。 FPTは、TFHEブートストラップを近似固定小数点演算で完全に実装することにより、FHE計算に存在する固有のノイズを大いに活用する最初のハードウェアアクセラレータです。 FHEに役立つ可能性のある別のプロジェクトは、クラウドでのFHE計算を大幅に高速化することを目的としたハードウェアアクセラレータのアーキテクチャファミリであるBASALISCです。

前述したように、FHE ハードウェア設計における主なボトルネックの 1 つは、メモリとの大規模な相互作用です。 この障壁を回避するための解決策として考えられるのは、メモリとの相互作用を可能な限り減らすことです。 このシナリオでは、プロセッシング インメモリ (PIM) またはニア メモリの計算が役立つ可能性があります。 PIMは、将来のコンピュータシステムが抱える「メモリの壁」の課題に対処するための有望なソリューションであり、メモリが計算機能とメモリ機能の両方を果たすことを可能にし、計算とメモリの関係を根本的に刷新することを約束します。 過去10年間で、抵抗性RAM、スピン伝達トルク磁気RAM、相変化メモリなど、この目的のための不揮発性メモリの設計は大きく進歩しました。 この特殊なメモリを用いて、機械学習や格子ベースの公開鍵暗号における計算量の大幅な向上を示す研究が行われています。

1. 最適化されたソフトウェアとハードウェア

最近の開発では、ソフトウェアはハードウェアアクセラレーションプロセスの重要なコンポーネントとして認識されています。 たとえば、F1 や CraterLake などの著名な FHE アクセラレータは、ソフトウェアとハードウェアのハイブリッド協調設計アプローチにコンパイラを使用しています。

この分野が進歩するにつれて、完全に機能するコンパイラがブロックチェーン固有のFHEコンパイラと共同で設計されることが期待できます。 FHEコンパイラは、それぞれのFHEスキームのコストモデルに基づいてFHEプログラムを最適化できます。 これらのFHEコンパイラは、FHEアクセラレータコンパイラと統合して、ハードウェアレベルの側面からコストモデルを組み込むことで、エンドツーエンドのパフォーマンスを向上させることができます。

1. ネットワーキング FHE アクセラレータ: スケールアップからスケールアウトへの移行

既存のFHEハードウェアアクセラレーションの取り組みは、主に「スケールアップ」、つまり単一のアクセラレータの垂直方向の改善に焦点を当てることに重点が置かれています。 一方、「スケールアウト」では、複数のFHEアクセラレータを水平にネットワーク化して接続することに重点が置かれており、ZKPによる並列プルーフ生成と同様に、性能を大幅に向上させる可能性があります。

FHEアクセラレーションの主な問題の1つは、データインフレーションの問題で、暗号化と計算中に発生するデータサイズの大幅な増加を指し、オンチップメモリとオフチップメモリ間の効率的なデータ移動に課題をもたらします。

データのインフレーションは、複数のFHEアクセラレータをネットワーク経由で水平に接続する上で大きな課題となります。 したがって、FHEハードウェアとネットワークの協調設計は、将来の研究の有望な方向性となるでしょう。 たとえば、FHE アクセラレータの適応型ネットワーク ルーティング: リアルタイムの計算負荷とネットワーク トラフィックに基づいて FHE アクセラレータ間のデータ パスを動的に調整するルーティング メカニズムの実装などです。 これにより、最適なデータ転送速度と効率的なリソース使用率が保証されます。

結論

FHEは、プラットフォーム間でデータを保護する方法を根本的に再考し、前例のないプライバシーの新時代への道を開きます。 このようなシステムを構築するには、FHEだけでなく、ZKPやMPCの大幅な進歩も必要です。

この新しいフロンティアに足を踏み入れるには、暗号学者、ソフトウェアエンジニア、ハードウェアスペシャリストの共同作業が不可欠です。 立法者、政治家などは言うまでもなく、規制遵守が主流採用への唯一の道です。

最終的に、FHEはデジタル主権の変革の波の最前線に立ち、データのプライバシーとセキュリティがもはや相互に排他的ではなく、密接に統合される未来の到来を告げるでしょう。

スペシャルサンクス:

Mason Song 氏 (Mind Network)、Guy Itzhaki 氏 (Fhenix)、Leo Fan 氏 (Cysic)、Kurt Pan 氏、Xiang Xie 氏 (PADO)、Nitanshu Lokhande 氏 (BananaHQ) に感謝します。 私たちは、これらの個人が現場で行っている印象的な仕事と努力について読むことを楽しみにしています!

免責事項：

1. この記事は[HashKey Capital]からの転載です。 すべての著作権は原作者[Jeffrey Hu、Arnav Pagidyala]に帰属します。 この転載に異議がある場合は、 Gate Learn チームに連絡していただければ、迅速に対応いたします。
2. 免責事項:この記事で表明された見解や意見は、著者のものであり、投資アドバイスを構成するものではありません。
3. 記事の他言語への翻訳は、Gate Learnチームによって行われます。 特に明記されていない限り、翻訳された記事を複製、配布、盗用することは禁止されています。