ハクソク

世界を動かす技術を、日本語で。

完全準同型暗号の初心者向け教科書

246日前原文(arxiv.org)

概要

Ronny Koによる論文や書籍の 提出履歴 について解説。 各バージョンの 提出日時 や ファイルサイズ を一覧化。 バージョンごとの 変更点や特徴 の把握に役立つ情報。 公式テキストへの ダイレクトリンク を紹介。 効率的な情報追跡や参照方法の提案。

Ronny Koによる提出履歴一覧

  • Ronny Ko による書籍または論文の提出履歴

    • [v1]: 2025年3月7日 04:29:11 UTC ( 33 KB)

    • [v2]: 2025年3月13日 15:18:50 UTC ( 5,237 KB)

    • [v3]: 2025年3月14日 03:22:13 UTC ( 5,239 KB)

    • [v4]: 2025年4月13日 13:14:01 UTC ( 5,258 KB)

    • [v5]: 2025年4月26日 18:20:16 UTC ( 5,275 KB)

    • [v6]: 2025年5月4日 15:31:10 UTC ( 5,302 KB)

    • [v7]: 2025年5月12日 17:20:32 UTC ( 5,099 KB)

    • [v8]: 2025年5月20日 16:04:22 UTC ( 5,062 KB)

    • [v9]: 2025年5月26日 03:42:34 UTC ( 5,062 KB)

    • [v10]: 2025年6月1日 08:45:01 UTC ( 4,570 KB)

    • [v11]: 2025年6月8日 04:45:52 UTC ( 4,571 KB)

    • [v12]: 2025年6月30日 13:04:04 UTC ( 4,570 KB)

    • [v13]: 2025年7月7日 09:54:47 UTC ( 4,570 KB)

    • [v14]: 2025年8月13日 04:21:08 UTC ( 4,570 KB)

    • [v15]: 2025年9月8日 05:39:49 UTC ( 4,570 KB)

    • 各バージョン のファイルサイズや提出日から、内容の追加・削除や修正の傾向を推察可能

公式テキストへのダイレクトリンク

  • 公式書籍 への直接アクセスリンク

    • https://fhetextbook.github.io/

    • 最新版の内容 や 詳細情報 の参照が容易

    • バージョンごとの違い を比較検討する際に有用

    • 研究者や学生 による効率的な情報収集を支援

提出履歴活用のポイント

  • バージョン管理 による進捗や変更点の把握
  • ファイルサイズ の変化から内容の増減や最適化を推測
  • 公式リンク から常に最新情報へアクセス可能
  • 履歴一覧 は論文引用やレビュー時の参照に便利
  • 継続的な更新 の証拠として信頼性向上に寄与

Hackerたちの意見

本の直接リンクはこちら: https://fhetextbook.github.io/

「良い」セキュリティを持つFHEスキームについて、（a）暗号化されたデータに対して行える操作の数には有限であまり大きくない制限があると思ってたし、（b）暗号側での各操作は平文の数やその他の操作よりもずっと高コストだと思ってたんだけど、間違ってる？内部がどう動くかは全然知らないって認めるよ。だって、その制限がほとんどの目的には使えないと思ってたから、学ぶ時間を取らなかったんだ。でも、抽象的にはFHEが機械学習モデルの実行に役立つって言ってるし、かなり大きなモデルのことを言ってるんだよね、たぶん。

└

どちらもまあまあ正しいかな。FHEスキームでは、復号せずに操作カウンターをリセットする再正規化ができるから、その意味では操作数に厳密な制限はないよ。ただ、FHEの操作は通常のものよりも約6桁高いコストがかかるから、例えばLLMをすぐに動かすのは無理だね。小さな分類器ならいけるかも。

└

ホモモルフィックスキームと完全ホモモルフィックスキームの違いは、FHEはブートストラップできるってこと。暗号化された値からノイズを取り除くホモモルフィックに評価できる回路があって、それによってどんなホモモルフィック計算の結果もノイズを取り除いてさらに計算できるようになるんだ。

└

私の理解は主に10年前のもので、全体的に高レベルで、完全同型暗号の一種類についてだけです。状況は変わっていて、今ではいくつかの種類があります。各ビットを暗号化して、その後「暗号化されたビット」を使って、平文に適用したい操作を実装する仮想ゲートベースの回路で評価するシステムだと聞きました。平文を（復号|暗号）化するための鍵は、少なくとも1ギガバイトになるでしょう。この指数的に大きなデータを処理するのが、私が説明したシステムに基づくFHEが遅い理由です。だから、例えば数字を足したい場合は、FHEシステム内でフルアダー回路を実装する必要があります。[0] https://en.wikipedia.org/wiki/Adder_(electronics)#/media/Fil... 250ページの論文より短くてわかりやすい概要を知りたいなら、ジェレミー・クンの2024年の概要を考慮してみてください。[1] https://www.jeremykun.com/2024/05/04/fhe-overview/

└

ゴールポストが動いて、もうプライベートじゃなくなった、ちょうどプライベートなだけ。

FHEの計算負担は、平文で同じ操作をするのと比べてどうなの？多くのクラウド支持者は、FHEがデータを安全に扱えるようにするかもしれないと思ってるけど（全部暗号化されてて、鍵も持ってないから、こっちの問題じゃない）、もしFHEがプロセッサの能力を100倍や1000倍増やす必要があるなら、大規模には実用的じゃないと思うんだ。

└

暗号化されてない計算より少なくとも100万倍遅いよ。1000倍や100倍なら大きな進歩だね。

└

そんな論文を読む時間があるなんて想像してみて。正直読みたいけど、これだけで30時間の勉強になるのは分かってる。

面白いことに、ニューラルネットワークは微分可能だから、ホモモルフィックに暗号化できるんだ！そう、君のLLMは秘密裏に何かを生み出せるようになるよ、へへ。

└

それはすごいけど、計算可能な関数はFHEを使って計算できるから、微分可能な部分が必要かどうかは疑問だな。

└

ニューラルネットワークでよく使われるReLUは、ゼロで微分可能じゃないけど、効率的にFHE評価可能な式で近似できるんだよね。もし細かいことを気にするなら、微分可能性は本当に重要じゃない。とはいえ、すごく洞察に満ちたコメントだね。FHEの下で動くLLM（または完全にローカルなLLM）は、人類にとって大きな前進だと思う。みんながプライベートにLLMとやり取りする権利を持つべきだ。それが目指すべき理想だね。

└

微分可能性はホモモルフィズムの要件じゃないと思う。ホモモルフィズムは、例えば私が双射関数 [1] f: A -> B と、Aの二項演算子 * とBの ’ を持っているとき、f(a1a2) = f(a1)’f(a2) ならfはホモモルフィックだと言える。ざっくり言うと「構造を保つ」ってこと。だから、fが私の暗号化なら、暗号の外で’を実行できて、fがホモモルフィックだから、結果は暗号の中で*を実行するのと同じになるってわけ。だから、暗号が同型である必要があって、暗号の中でやりたい操作の「暗号の外での」バリエーションが必要なんだ。それは微分可能性とは別の要件だよ。1: 双射関数は一対一の対応を意味する 2: ホモモルフィズムの性質を持つ双射関数は同型と呼ばれて、例では集合Aを集合Bと同等にする。

タイトルが壊れてる？「Unified Line and Paragraph Detection by Graph Convolutional Networks (2022)」って見えるんだけど。

└

同じことを思った。HNのフロントページにもそのタイトルの投稿があって、正しい論文にリンクしてるんだよね。何が起こってるのか気になる。

└

返信が遅れてごめん。これは多分バグだと思うけど、すごく変なんだ…今、モデレーターにメールしたところ。

└

申し訳ない。これは完全に私のミスだった。あの時、arxiv.orgからの投稿が（少なくとも）2つあって、もう一つのタイトルを更新してる時に、こっちに適用しちゃったみたい。今は修正したし、正しいタイトルでフロントページに再アップしたから、ちゃんと目立つようになったよ。

いや、そんなに悪くないよ。もうすぐFHEを使ったプロダクションの消費者アプリが使えるようになるんだ。

300ページ近くあるのに、参考文献が26件しかないのには驚きました。決して大したことではないけれど、明らかに多くの作業が入っているのは分かります。他のテーマとの重なりを参考文献から見るのは役に立ちますね。

参考までに: プライバシーを保護する適度なサイズのMLモデルに役立つかもしれないコンパクトなゼロ知識証明のためのGitHubリポジトリを作りました。(https://github.com/logannye/space-efficient-zero-knowledge-p...) 残念ながら、FHEの計算オーバーヘッドは、非常に小さなモデルでない限り、MLワークロードを実行するには依然として高すぎます。ZKMLをもう少し実用的にする手助けができればと思っています。

└

すごく面白そうですね。ZKをMLにどう適用するのか詳しく教えてもらえますか？（それとも、何かリソースを教えてもらえますか？）

└

Zama.aiのFHEに関する研究はチェックしましたか？