導入
FHE はゲームを変えており、私たち全員が参加するよう招待されています。
私が何を言っているのか全く分からないのなら、それはあなたが最近世間知らずだったということです。FHE.orgの包括的なリソースをいくつか閲覧してから戻ってきてください。
FHE がテクノロジーの世界にその約束を果たすには、誰でも簡単に準同型アプリを構築できる、開発、コンパイル、ランタイム実行のための新世代の産業用ツールが付属している必要があります。
しかし現時点では、FHE 分野の多くの専門家や企業は、非専門家向けの優れた開発ツールの構築に注力するのではなく、FHE の背後にある暗号技術の改善に時間と労力の大半を費やしています。よく聞いてください。FHE のコア機能とパフォーマンスの向上は常に良いニュースです。しかし、全体的な計画では、これらの漸進的な改善はせいぜいわずかに世界的な採用を促進するだけです。いつかは採用に影響を与えるでしょうが、今すぐではありません。
私の立場からすると、FHE を活用した成功事例を解き放ち、FHE を技術トレンドからデジタル セキュリティ ビジネスにおける実際のパラダイム シフトへと移行させるためには、テクノロジーの世界が今日、強力で開発者に優しい FHE ツールチェーンを必要としていることは明らかです。科学的にも技術的にも、FHE に関する現在の知識は、現時点でそのようなツールを構築し、技術に精通した大衆が遅滞なく利用できるようにするのにすでに十分であると私は信じています。新機能の継続的な統合は、常に時間の経過とともに自然に展開されます。
しかし、ここで問題なのは、FHE にはさまざまな種類があるということです。使用している暗号化方式、またはそれを具体的にどのように使用するかに応じて、計算を表現し、準同型プログラムを実行する方法が異なります。FHE 方式は、1 つはチューリング マシンを提供し、もう 1 つはラムダ計算を提供する、まったく異なる種類のものであるようなものです。生物多様性は、テクノロジーでもその他の面でも常に良いことですが、実際に FHE を実装するときには、実行可能な戦略を固める必要があることも意味します。
私の会社Zamaは、 TFHEという特定の FHE スキームに注力しています。TFHE は、超高速ブートストラップとテーブル検索のネットワークとして表現される計算という非常に特殊な機能を使用して、準同型データ処理を実現します。TFHE を FHE 分野である種の弱者にしていたこれらの特殊性を、準同型ライブラリ、コンパイル、仮想マシン、またはハードウェア アクセラレーションにどのように変換できるかについて、私たちは深く理解するようになりました。
CKKS 、 BGV 、 BFVなどの他の著名な FHE 候補は、実際の計測に非常に異なる概念を取り入れています。ブートストラップはオプションとしては遅すぎるため、処理の深さは制限されますが、データは大規模なバッチ処理でベクトル化でき、計算は多項式回路として表現され、CKKS の場合は結果は近似値になります。そのため、BGV/BFV および CKKS をコンパイラーとランタイムに変換するには、ツール開発者とはまったく異なる考え方が必要です。
ただし、開発者は、簡単に操作でき、デプロイされた準同型アプリケーションでパフォーマンス要件が満たされている限り、FHE ツールチェーンとランタイム環境がどの特定のスキームによって実行されているかについてはあまり気にしないでしょう。開発者自身がクリエイティブなビルダーであり、ユーザーに提供できる新しいエクスペリエンスに重点を置く必要があります。
したがって、FHE テクノロジーの実現者にとっての最終目標は、開発マルチバースで最盛期を迎える準備が整っているだけでなく、新しい業界標準を設定できるほど強力なツールを考案して提供することです。これを達成するには、どの FHE スキームがそこに到達する可能性が高いかを判断する必要があります。
ゲームをしましょう。
FHE の複雑さについて何も知らないが、準同型アプリケーションを構築したい開発者を考えてみましょう。ここではツール ビルダーであるあなたがその開発者と対峙します。その開発者は、一般的な開発手法やコンピューター サイエンスの基礎についてはある程度の知識があると考えられますが、高度な数学など、それ以外のことはまったく理解できません。どうすれば、FHE アプリを独力で作成させることができるでしょうか。
この記事では、TFHE に賭けてそのゲームに勝つためのさまざまな戦略について説明します。
アプリケーションの性質（カスタム データ処理、ニューラル ネットワーク、スマート コントラクト、汎用プログラミング）に応じて、TFHE 対応の成功への道が模索されます。この模索では、実用化に向けたさまざまなレベルの技術的準備状況に応じて、簡単な道、困難な道、およびその中間のいくつかの道をたどることになります。
TFHE プログラムとは何ですか?
TFHE は Torus FHE の略です。発見者の名前にちなんで CGGI とも呼ばれる TFHE は、FHE 分野において独自の位置を占めており、プログラム可能なブートストラップ (PBS) を可能にする最もよく知られたメカニズムです。
簡単に言えば、PBS は準同型テーブル検索です。インデックスxの暗号化が与えられた場合、 T[x]の暗号化を返します。ここで、 Tは選択した表形式の関数です。実行速度はTのエントリではなくエントリ数にのみ依存し、数ミリ秒の範囲です。さらに、PBS は出力暗号文に埋め込まれた暗号化ノイズをリセットするため、準同型アプリケーションが常にクリーンな暗号文を処理することを知りながら、PBS を無期限に連続して作成できます。
TFHE ネットワーク
TFHE が提唱する計算モデルは典型的なものです。
TFHE プログラムの基本処理ユニットはニューロンとまったく同じように見え、2 つの基本的な準同型演算を構成します。
暗号化された入力 E
E(x)E(x_1), …, E(x_n)とプレーンテキストの重みセットw_1, …, w_nが与えられた場合、x = w_1 x_1 + … + w_n x_n modulo mとなる E(x) を返す入力の線形結合。
E(x)からE(T[x])を計算するPBS。ここでTサイズmのプレーンテキストテーブルです。
「TFHE ニューロン」では、 m 、 x_i 、 w_i 、およびエントリT[0], …, T[m-1]すべて整数であり、「パラメータ」 m 、 w_1, …, w_nおよびTを自由に選択できます。線形結合のコストがほぼゼロであることを考えると、効率のボトルネックとなるのは、実行時間がモジュラスmのみに依存する PBS です。つまり、 m増加すると速度が低下します。これにより、TFHE ニューロンのモジュラスに小さな値 (奇数または偶数、ただし少なくとも 2) を使用できますが、計算表現力が極端に低下しないようにトレードオフを見つける必要があります。
さて、ニューラル ネットワークでニューロンが層に組み立てられて並列処理と HPC トリックの恩恵を受けるのと同じように、TFHE ネットワークは TFHE ニューロンの層を積み重ねます。各層は、共通係数mを法とする重み行列と、サイズmのルックアップ テーブルのベクトルを備えています。ただし、係数は、層の形状と同様に、前の層または次の層で自由に変更できます。
これで TFHE は完了です。関数をルックアップ ネットワークとして体系的に表現するだけです。これで準同型計算モデルが完成しました。
実際には、TFHE はそのモデルの複数の拡張機能 (低レベルの演算子の任意のグラフ、さまざまなタイプの暗号文、複数出力テーブル検索、変数をパックする複数の方法など) をサポートしています。ただし、検索ネットワーク ビジョンはすでに十分に強力で、単純なプログラムを準同型に変換して実行できるため、今のところこれらの拡張機能は無視できます。そのため、少なくともテクノロジの最初の反復では、それを実行する方法に集中できます。
TFHEネットワークを実行可能にする
そのため、TFHE ネットワークは単なる青写真であり、準同型アプリ内で適切に実行する準備はまだ整っていません。すべてのレイヤーの係数、重み行列、ルックアップ テーブルが完全に指定されているにもかかわらず、暗号パラメータ化という重要な要素がまだ欠けています。
暗号パラメータは、実行時にネットワーク内で何が起こるかについてのあらゆる可能なメトリックを決定します。具体的な暗号文のサイズ、PBS 内部のキー切り替えおよびブートストラップ キーの実際のテンソル次元、低レベル準同型演算子内のさまざまなアルゴリズム オプション、ネットワーク全体でのプレーンテキストの精度とノイズ レベルの変化、そして最終的には暗号化と復号化の方法の詳細などです。また、メモリ使用量とパフォーマンスも予測します。
TFHE ネットワークの実行を最適化するパラメータ セットを見つけるのは面倒な作業になる可能性があり、いずれにしても、すべてがすべてに依存するため、FHE の初期の頃のように紙とペンで調べるのは、専門家にとっても非常に困難です。また、複数の最適なセットが同時に共存する可能性があるため、公開キーのサイズ、クリティカル パスの遅延、または最大スループットの間で裁定が必要になります。幸いなことに、このタスクを自動化する問題はここ数年で解決され、特定の TFHE ネットワークの最適な暗号化インスタンスを迅速に決定するための強力な最適化ツールが現在存在します。
暗号化パラメータを使用してインスタンス化されると、TFHE ネットワークは実際に実行可能になります。より正確に言うと、適切なコンパイル パスを通じて、実際に実行可能になります。
TFHEプログラム
TFHE プログラムは、「プレーン ロジック」によって結合されたパラメーター化された TFHE ネットワークのコレクションです。
平易な論理は
平文変数（通常の暗号化されていない変数）を操作する命令
条件なしまたはプレーンテキスト述語に条件付きの分岐、
プレーンテキストアドレスでのメモリの読み書き、ポインタ演算、
サブルーチン/関数の呼び出し。
基本的に、プレーン ロジックには、言語でサポートされているすべてのプログラミング ロジックが含まれますが、暗号化されたプログラム変数を変更するという 1 つの例外があります。これは、プログラムの TFHE 部分の特権です。プレーン ロジックが暗号文 (および TFHE 公開鍵も同様) に対して実行できる唯一のことは、暗号文を変更せずに移動して、TFHE 部分が独自のコプロセッサまたはコンテナー内で実行されているかのように、TFHE 部分に渡すことです。
事実上、この定義に準拠するプログラムは、プログラミング言語に関係なく、完全な準同型アプリケーションになる準備が整っています。カスタム コンパイルによってこの最終的なマッピングが提供され、結果のオブジェクトは、TFHE 対応ランタイム上で実行することも、スタンドアロンの自己完結型実行可能ファイルとして実行することもできます。
専用の言語 (DSL や、より適切なMLIR 方言など) を使用して TFHE プログラムの表現を統一し、同じバックエンド コンパイラでコンパイルを実行できるようになります。
ランタイムの正確な性質 (共有/動的ライブラリ、VM など) は、ここでは単なる形式です。どちらのオプションでも、TFHE を利用した準同型アプリが稼働し、ユーザーに展開して公開できるようになります。
さて、ちょっとゲームに戻りましょう。
私たちが直面しているのは、TFHE や上記について何も知らないが、準同型アプリケーションを構築したい開発者です。上で説明したコンパイラと、TFHE 対応のランタイム (存在する場合) がリリースされていると仮定します。
目標は決まっています。あとは実行ファイルを作成するための TFHE プログラムだけです。しかし、そもそも開発者に TFHE プログラムのような特殊なものを自分で作成させるには、どうしたらいいのでしょうか?
簡単な方法: FHE ライブラリをリリースして、開発者に任せる
ここで簡単な勝利の道が開かれます。すべての複雑さをブラックボックスの FHE API にカプセル化します。
単純なプログラム
どのプログラミング言語でも、（単純な）プログラムは基本的に次の 3 つの要素の組み合わせとして考えることができます。
言語固有の命令とスコープ構造から構成されるプログラムロジック
変数と、プログラムがそれらに割り当てるデータ型の選択（すべての可能なデータ型から選択）
プログラムが変数を操作するために使用する、利用可能なすべての外部関数の中から選択された外部関数の呼び出し。
データ型には独自のサブ言語があり、ネイティブ型と、これらのネイティブ型を拡張してより高レベルの構造型に結合する型付け構造が混在しています。型システムは、プログラムに必要なほぼすべてのデータ構造をカバーするのに十分な表現力を提供することを目的としています。外部関数は、標準またはその他のライブラリによって提供されるものですが、言語固有の命令によって暗黙的に呼び出されることもあります (モジュラー算術や除算の演算子を考えてみてください)。
つまり、単純なプログラムは実際には「シンプル」なのです。
ここで私の言うことをよく聞いてください。多態性、メンバーと属性を持つオブジェクト、クラスと階層的継承、テンプレート、マクロ、特性、スレッド、再帰、糖衣構文、注釈、および言語によって提供されるその他考えられるすべてのゼロコストの抽象化などの高レベルプログラミング概念のすべてが、開発者の作業を簡素化するために発明されたものではありますが、開発者にとって扱いやすいものであると言っているわけではありません。
私が言いたいのは、私たちの目的にとって、それらはコンパイル時に消える無害な装飾に過ぎないということです。なぜなら、簡略化されてはいるものの同等の正規形バージョンのプログラムがソースから推論されるからです。中間表現 (IR) で表現されるそのバージョンのプログラムは、何らかの制御フロー グラフで接続された直線的な基本ブロック (その IR で基本的な命令のシーケンス) で構成されています。
さて、この正規形のプログラムは「シンプル」です。つまり、準同型機能で拡張できるほどシンプルです。
FHE を写真に映し出す
言語ネイティブの FHE ライブラリをリリースし、開発者にそのライブラリを最適に使用する方法を任せることで、ゲームに勝利できます。
ライブラリは、新しいデータ型 (プレーンなデータ型を補完する暗号化されたデータ型) と、開発者が使い慣れているプレーンな関数を (多かれ少なかれ) 模倣した準同型関数のコレクションを公開します。ただし、これらの関数は暗号化されたデータ型で動作します。つまり、型システムとライブラリ エコシステムを拡張し、開発者の知恵でこれらの拡張機能を使用して準同型アプリを作成する方法を見つけ出すことになります。
これは特に TFHE に関係するものではなく、どの FHE スキームでも機能します。これが、さまざまな FHE ライブラリのプロバイダーが注力していることです。つまり、見た目も操作感もできるだけプレーンなコーディング エクスペリエンスに近い高レベルの準同型関数を公開することで、FHE の使いやすさとユーザー フレンドリさを向上させることです。暗号の複雑さはすべてブラック ボックスに抽象化され、プログラムがオラクル呼び出しを行います。
もちろん、開発者にとっては、それはうまくいくかもしれません。まあ...それは、ライブラリプロバイダーとしての契約のあなたの側の義務を果たせばですが。
彼らは、次のような準同型プログラムを解明するでしょう。
現在、プレーン変数と暗号化変数が共存しており、プログラムはこれら 2 つのオブジェクト タイプを厳密に区別する必要があります。これは、プレーン引数と暗号化引数の混合に関数を適用すると、結果が必ず暗号化されるという FHE の黄金律があるためです (例: fhe_add(E(x), y)はE(x+y)を返します)。したがって、プレーン変数は一部の FHE 関数に入ることはできますが、そこから出ることはできません。準同型暗号化は、計算を通じて触れるものすべてを「汚染」します。
では、暗号化された変数に条件付きで分岐するにはどうすればよいでしょうか?
まあ、それはできません。でも、それはまったく大きな問題ではありません。
唯一の問題点: 条件分岐
FHE アプリケーションでは、条件分岐は暗号化されたブール値ではなく、プレーンなブール値に対してのみ機能します。暗号化されたビットに基づいてどこにジャンプするかをどうやって知るのでしょうか? そのビットを復号化するためのユーザーの秘密鍵はありません。
幸いなことに、FHE ではこれを解決するための簡単なコツも提供されています。
ifを正規化する方法
開発者が当初、次のようなことをしたいと考えていたとします。
if (x == 0) then y = 3 else z = 7
しかし、その時点では変数xは実際に暗号化されていることがわかります。そのコードをどのように適応させるのでしょうか?
最初に行うべきことは、単純なifステートメントを作り直して、多重化を使用する同等の直線コードを作成することです。
bit = (x == 0) // bit = 1 if x == 0 otherwise 0 y = 3 * bit + y * (1 - bit) // y = 3 if bit == 1 otherwise no change z = z * bit + 7 * (1 - bit) // z = 7 if bit == 0 otherwise no change
2 回目のパスでは、開発者はxが暗号化されたタイプであるという事実を後続の行に伝播する必要があります。
bit = fhe_is_equal(x, 0) // bit, y_new and z_new are encrypted y_new = fhe_add(fhe_mul(3, bit), fhe_mul(y, fhe_sub(1, bit))) z_new = fhe_add(fhe_mul(z, bit), fhe_mul(7, fhe_sub(1, bit)))
これが開発者の当初の意図と機能的に同等であることを確認できます。それだけです。
プログラミング言語でネイティブ演算子のオーバーロードが許可されている場合、FHE API は 2 番目のスニペットの明示的な FHE 関数を不要にすることもできるため、開発者が行う必要があるのは最初の書き換えだけです。
開発者にさらに構文上の糖衣を与えるために、オーバーロードされた三項演算子a? b : cを公開することもできます。この場合、引数は暗号化することも、暗号化しないこともできます。コードはさらにシンプルになります。
bit = (x == 0) // bit = 1 if x == 0 otherwise 0 y_new = bit? 3: y // y = 3 if bit == 1 otherwise no change z_new = bit? z: 7 // z = 7 if bit == 0 otherwise no change
これは、任意のif/switchステートメントに簡単に一般化できます。暗号化された条件をチェックするたびに、開発者は多重化を使用して、ステートメントの複数の本体を 1 つの同等の直線コード ブロックに融合するだけです。
for/whileループを正規化する方法
暗号化された条件を含むループ構造も同じように正規化できる。例えば
for (i = 0; i < x; i++) do <body> // i is plain, x is encrypted
ここで、 x暗号化された型になります。まず、これを単純なfor文と不規則なif文に分解します。
for (i = 0; i < known_max_value_of_x; i++) do if (i < x) then <body> // i is plain, x is encrypted
そして、前と同じようにifステートメントを正規化します。
for (i = 0; i < known_max_value_of_x; i++) do bit = (i < x) // i is plain, x and bit are encrypted <new_body> // new body regularized using bit? _ : _
これには、即時値known_max_value_of_xが必要であることに注意してください。暗号化されたタイプのxでサポートされている最大値はデフォルトで使用できますが、多くの場合、開発者はxのより良い上限を知っており、これにより、合計ループ数を厳密に最小限に減らすことができます。
結局のところ、上記の変換は、不規則な制御フローを正規化する体系的な方法に簡単に一般化でき、コーダーが簡単に理解してコーディング習慣に追加できます。
例: EVM 上の機密スマート コントラクト
Zama のfhEVMは、Ethereum Virtual Machine (EVM) 上で機密性の高いスマート コントラクトを開発および展開するための本格的なオープン ソース フレームワークです。fhEVM コントラクトは、従来の Solidity ツールチェーンを使用して構築されたシンプルな Solidity コントラクトです。使い慣れた開発エクスペリエンスは、暗号化されたデータ型と標準関数の FHE 置換を提供するライブラリTFHE.solによって FHE で強化されています。
現在サポートされている暗号化データの種類は
ebool, euint4, euint8, euint16, euint32, euint64, eaddress
暗号化された符号付き整数も間もなく含まれるようになります。暗号化された変数は、専用のコンストラクタを使用して生の入力暗号文から作成されます。
function mint(bytes calldata encryptedAmount) public onlyContractOwner { euint64 amount = TFHE.asEuint64(encryptedAmount); balances[contractOwner] = balances[contractOwner] + amount; totalSupply = totalSupply + amount; }
Solidity のネイティブ演算子+, -, *, &, |, ^, etc開発者の利便性のためにオーバーロードされており、提供されている比較演算子eq, ne, gt, lt, ge, le暗号化されたブール値eboolを返します。準同型三項演算子_? _ : _ selectと呼ばれます。
function bid(bytes calldata encryptedBid) internal { euint32 bid = TFHE.asEuint32(encryptedBid); ebool isAbove = TFHE.le(bid, highestBid); // Replace highest bid highestBid = TFHE.select(isAbove, bid, highestBid); }
ランタイム側では、fhEVM は、オープンソースのTFHE-rs Rust ライブラリの統合の結果として、準同型関数が事前コンパイルされたコントラクトとして公開される TFHE 対応の EVM を提供します。
詳細については、fhEVM のホワイト ペーパーを参照してください。
TFHE を使用して FHE API を構築するには何が必要ですか?
実行可能な TFHE プログラムが、単純なロジックで組み立てられたパラメーター化された TFHE ネットワークのように見えることを覚えていますか? 開発者のソフトウェア ロジックをそれにマッピングする方法が必要です。
最初の要件は、プログラム ロジックが「明確」であることを確認することです。これは、制御フロー ステートメントを正規化することによって開発者が自分で作成するように教えた内容とまったく同じです。そのため、現在ではその点では問題ありません。
2 番目の要件は、プログラムによって呼び出されるすべての準同型関数を、事前に確立されたパラメーター化された TFHE ネットワークにマッピングする必要があることです。これは、いくつかの理由により、見た目よりも複雑です。
1. API関数用のTFHEネットワークを作成する必要があります
特定の機能を実装するパラメーター化された TFHE ネットワークを事前に確立することは、必ずしも簡単ではありません。
暗号化された 2 つの 64 ビット符号なし整数の準同型加算を構築するだけで、多くの技術的オプションが生まれます。64 ビット入力をモジュラー整数のベクトルとしてどのように表現するのでしょうか。正確にはどのような係数 (または複数の係数) を使用するのでしょうか。また、テーブル参照のレイヤーを使用して 64 ビット加算回路を実現するにはどうすればよいでしょうか。
選択肢はたくさんあります。しかし、最終的には、優れたエンジニアリングと多くの実験を通じて決断を下すことになります。
2. 暗号化されたデータタイプを正規化する必要がある
API のすべての機能に対して TFHE ネットワークを実装したと仮定すると、レゴ ブロックのように自由に構成できることを確認する必要があります。
これは必ずしも保証されるものではありません。同じ暗号化されたデータ タイプを表現する最適な方法は関数ごとに異なる場合があるからです。そのため、TFHE ネットワークの効率をあまり低下させずに、暗号化された各データ タイプを表現するために共通の算術形式を採用する必要があります。
繰り返しになりますが、選択肢はたくさんあるので、それらの間で裁定取引を行う必要があります。
3. 実際のコンポーザビリティを保証する必要がある
すべての TFHE ネットワークが入力/出力形式で完全に互換性があると仮定しても、コンポーザビリティはまだ保証されない可能性があります。
これは、1 つの TFHE ネットワークをインスタンス化する暗号化パラメータが、別の TFHE ネットワークをインスタンス化するために使用されるものと互換性がない可能性があるためです。特に、実際の構成可能性を確認するには、入力および出力暗号文内の暗号化ノイズのレベルを調整する必要があります。
これは電子回路のインピーダンスに似ています。インピーダンスが一致しないと、ある回路を別の回路に接続することはできません。まず、インピーダンス レベルを揃える必要がありますが、ここでも同じです。最も簡単な方法は、すべての API 関数間での整合を確保するように調整された固定パラメータ セット (1 つの一意のセットでもかまいません) を使用することです。その後、開発者がコーディングする内容に関係なく、ユーザーの公開キーの形式と、ユーザーの暗号化および復号化で使用されるパラメータが固定されます。
TFHE ネットワークを作成してパラメータ化する際に、これら 3 つの要件を満たし、全体的なパフォーマンスも良好にする方法が見つかった場合は、おめでとうございます。成功です。
では、なぜ FHE ライブラリでは十分ではないのでしょうか?
これらは、FHE API が、開発者が期待するすべての標準関数の準同型置換を完全な構成可能性で提供できるほど包括的であると仮定すると、汎用プログラミングには十分です。
しかし、専門分野に特化したプログラムには不十分かもしれません。
機械学習のような大規模で計算集約的な機能、
カスタムの非標準関数。
ここで準同型コンパイルが登場します。
困難な道: 準同型コンパイラのリリース
厳しい道はここから始まります。汎用プログラミング以外の分野で勝つためには、TFHE コンパイラーを提供する必要があります。
コンパイラは、開発者が自分でどうすればよいかわからない部分を処理します。コンパイラは開発者の入力 (それが何であれ、それはあなたの判断です) に基づいて、不足している部分を完成させて TFHE プログラムを完成させます。
非標準アプリケーションの典型的な例を見てみましょう。
ディープニューラルネットワークによる機密推論
開発者は、単純なニューラル ネットワークを準同型ネットワークに変換することで、ユーザーの入力と出力がエンドツーエンドで暗号化される準同型推論サービスを構築して展開します。
開発者が入力として提供するもの
開発者は、トレーニング済みの量子化モデルを作成できるほど機械学習に精通しているか、すでにそのようなモデルを所有している必要があります。
量子化がどのように行われるかという詳細は、ここでは本当に重要です。コンパイラーは、モデルが基本的に TFHE ネットワークであること、または単純な書き換えによって簡単に TFHE ネットワークに対応できることを要求するからです。利用可能なオープンソース技術は、事前トレーニング済みモデルを事後量子化するか、または可能であれば同じデータセットでトレーニングされた非量子化モデルと比較して最高レベルの精度を達成する量子化認識トレーニング (QAT) を実行することによって、その形式の量子化をサポートすることが知られています。
本質的に、TFHE ネットワーク層全体で使用される係数は 2 の可変累乗であるため、活性化信号の精度はビット単位で測定されます。重みは符号付き整数であり、活性化関数自体は量子化され、テーブル ルックアップとしてインスタンス化されます。活性化が学習されたオフセットでシフトされたハード符号関数を表にする場合、この定義にはBNN 、 TNN 、およびそれらのマルチビット一般化などのモデル タイプが含まれます。ただし、原則として、活性化関数で任意のルックアップ テーブルを自由に使用できるため、トレーニング中にそれらを学習して精度を向上させることもできます。
しかし、開発者が知らないのは、TFHE ネットワークを準同型実行可能ファイルに変換することです。したがって、ここで欠けている唯一の要素は、そのネットワークの暗号化パラメータ化だけです。これは、バックエンドのコンパイル段階に進む前にコンパイラが行う必要があるすべてです。
TFHE ネットワークをパラメーター化するには何が必要ですか?
TFHE ネットワークのパラメータ化により、実行可能な暗号化インスタンスが提供されることに注意してください。また、ユーザーの公開キーの合計サイズや合計実行時間など、その実行に関連するすべてのメトリックも制御します。したがって、開発者は推論の遅延を絶対的に最小限に抑えようとしているため、パラメータ化はここで非常に重要です。
TFHE ネットワークの暗号化パラメータには自由度が多すぎるため、すべてをブルートフォースで解読することはできません。また、最適化するメトリックは、ネットワークの外部にある 2 つのコンポーネントと、ランタイムが低レベルの TFHE 操作を実行するために使用するアルゴリズムに依存します。
ノイズ式のコレクション。ノイズ式は、演算子のパラメータを未知の変数として使用して、演算子のエンドポイントでの暗号化ノイズの入力分布と出力分布を関連付けます。これらを確立するには、人間による科学的分析と実験による検証が必要です。
コスト メトリックのコレクション。コスト メトリックは、オペレーターの多次元効率 (メモリ使用量、実行時間など) をパラメーターの関数として予測します。通常、コスト メトリックは、ベスト フィット分析を通じてベンチマーク測定から推測されます。
ランタイムの実装の変更は、アルゴリズムとハードウェアに大きく依存するため、これら 2 つのモジュールに反映される必要があります。
ランタイムのノイズ式とコスト モデルは、指定された TFHE ネットワークとともに、最適化問題の全クラスの特定のインスタンスを作成し、このインスタンスは専用のオプティマイザーに渡されます。ここでは複数の目的を持つ混合整数非線形計画法について話しているので、最適なパラメーター セットのパレート フロントを見つけるには、その非自明なクラスの最適化問題を解決する必要があります。
技術的準備
優れた科学と工学により、このタイプの最適化の問題は数秒で解決されるようになり、 Concreteなどの TFHE コンパイラーにはすでに効率的な TFHE パラメーター オプティマイザーが内部モジュールとして組み込まれています。
将来的にはさまざまな改善により TFHE オプティマイザーの速度がさらに向上する可能性がありますが、たとえ改善がなくても、TFHE ネットワークのパラメーター化はほぼ完了していると考えられます。
高速カスタムデータ処理
開発者が入力として提供するもの
これらのアプリケーションは全く異なる種類のものです。開発者は、実装するカスタム関数の数学的仕様と精度制約を保持します。例えば、
ここでx 0から1までの実数であり、 Fの近似値Gを使用することは、
開発者は、標準 API 関数を作成してG封筒の裏に実装することは、おそらく最適とは言えない結果になるだろうと認識しています。
コンパイラは、 Gの仕様を満たすように特別に設計された新しい TFHE ネットワークをオンザフライで作成します。次に、それをパラメーター化し、バックエンドのコンパイルに進んで準同型アプリを生成します。
TFHE ネットワークを合成するには何が必要ですか?
さて、そこで道は突然、非常にでこぼこになります。
現時点では、先ほど述べた定義どおりの TFHE ネットワークを自動的に合成する方法についての科学的知識が不足しています。整数値のモジュラー演算に依存する隣接タイプの回路の合成に関する研究さえ、ほとんど行われていません。言うまでもなく、このタスクを A から Z まで実行できる既存のシンセサイザーはありません。
ブール合成を活用する
この問題を解決する一つの方法は、TFHEネットワークの計算能力の一部をブール回路にまで下げることである。例えば、TFHEニューロンを3値ブールゲートとして動作させるように強制することができる。
による
- 入力数を3に設定し、
x_1, x_2, x_30/1の値に設定すると、 - 係数を
m = 4、重みを(w_1, w_2, w_3) = (2, -1, 1)に設定すると、 - ルックアップテーブルを
[0, 1, 1, 0]に設定します。
同じ係数を持つすべての可能な重みとテーブルを総当たりすると、3値ゲートを計算するのに役立つTFHEニューロンの辞書を構成できます。次のステップは、
- ブール合成ツールを使用して開発者の仕様からブール回路を生成する（これを行うためのオープンソースツールは多数あります）。
- 回路を辞書に属する3値ゲートに分割（3方向LUT分割ともいう）する。
- これらの三元ゲートを同等のニューロンに置き換えると、
- 回路を最小限の深さの階層化ネットワークに再形成します。
これは、ブール回路に依存する手法がたくさんあるため、多くの例示的な戦略の 1 つにすぎません。通常のバイナリ ゲートを検討し、制約付き TFHE ニューロンで実装することもできます。CEA のCingulataと、その後の Google のFHE トランスパイラは、まさに TFHE でその道を切り開きました。
技術的準備
ブール合成では積極的な回路最適化技術が使用され、全体としては解決済みの技術的問題となっています。あるいは、ほぼ解決済みであるため、コンパイラを構築する人にとってそのアプローチは健全かつ実用的です。
しかし、TFHE ネットワークがそのように生成されると、その幅と深さが異常に高くなり、全体的なパフォーマンスが低下する可能性があります。そのため、TFHE ニューロンの (完全に人工的な) ブール条件付けを緩和することで、その表現力を最大限に活用し、はるかに小さく、はるかに浅いネットワークを実現できるのではないかという疑念が広まっています。
しかし、もう一度言いますが、それをどのように行うかを明確に特定するには、さらなる研究が必要です。機械学習から借りた適切なトレーニング方法を使用して TFHE ネットワークを学習するなど、まったく異なるアプローチが、最終的に優れた結果をもたらす可能性があります。時が経てばわかるでしょう。
包括的なTFHEコンパイラの探求
合成問題が解決され、効率的なカスタム TFHE ネットワークが生成される場合、すべての可動部分をまとめて、すべてを実行するコンパイラを設計する準備が整います。
入力としてプレーンなプログラムを受け取り、機密変数には暗号化されているという注釈が付けられるだけです。
事前にトレーニングされたニューラル ネットワークまたはその他の機械学習モデルを受け入れ、それらを TFHE ネットワークとして再解釈します。
数学的な仕様だけで作成された関数のモックアップを受け入れ、オンザフライ合成を実行してカスタム TFHE ネットワークを生成します。
必要に応じて、最適化モジュールを使用して、コンパイル ユニット内に残っているすべてのパラメーター化されていない TFHE ネットワークを実行可能なインスタンスに変換します。
さまざまなターゲット TFHE ランタイムやハードウェア アーキテクチャのコンパイルのバックエンド ステージを実行します。
特定のハードウェア アクセラレータ (そのコスト モデルを通じて) を活用して、より高速な TFHE ネットワークの合成とパラメーター化を可能にします。
いや、制御フローの自動正規化のサポートをそこに追加して、開発者がそれ以上気にしなくて済むようにしたほうがいいかもしれません。
これにより、 FHE アプリ開発者は究極の開発エクスペリエンスを実現できます。
まとめ
汎用 FHE プログラミングのコンテキストでは、TFHE ライブラリは、既存のツールチェーンを使用してモジュール性と完全に自律的な開発エクスペリエンスを提供できます。
TFHE は、その先にある開発者のニーズを満たすことができる特定のコンパイル手法の先駆者であり、特に暗号化された機械学習の推論や、今後数年間で高速暗号化データ処理やその他のカスタム FHE アプリケーションのニーズを満たすことができます。
全体として、TFHE は、ソフトウェア開発の世界で大きな成果を上げ、誰でもこれまでにない容易さで構築および実行できるプライバシー重視のソリューションの新しい波を生み出すことができる、より統合され適応性の高い FHE ツールチェーンを作成するための明確な技術パスを提供します。
TFHE ルックアップ ネットワークのみに焦点を当てることで、TFHE がサポートできる複数の計算モデルのうちの1 つを使用しました。研究によってその機能が徐々に明らかになるにつれて、TFHE を計測する新しい方法が出現することは間違いありません。
どれがいつなのかは別の話です。しかし、その話の背後には、機密コンピューティングの将来に関する、他の多くの興味深く、啓発的な疑問が潜んでいます。
