2024/1/23(木)にEthereum FoundationのPrivacy Scaling Explores(PSE)チームでソフトウェアエンジニアとして活動する、堤隆道さんをお招きし、ゼロ知識証明（ZKP）、完全準同型暗号（FHE）、秘密計算（MPC）といった先端的なプライバシー保護技術について、PSEチームが実際に取り組んでいるケーススタディを交えながらご講演いただきました。

講演では

1. PSEについて
2. Web3におけるプライバシーの課題
3. 暗号技術の紹介
4. 事例紹介

についてご説明いただきました。

以下に当日の講演資料と講演のアーカイブリンクを記載いたします。

資料リンク：https://docs.google.com/presentation/d/1kcuZAOJEvcI-guvrO1uQWazL-6NI2zUJw-Ayoi9jorw/edit?usp=sharing

アーカイブリンク：

以下に講演でご紹介いただいた内容を簡単にレポートいたします。

1.PSEについて

PSEチームはProgrammable Cryptographyの利活用を促進してHuman Collaborationを推進する研究組織で、ZKP, MPC, FHEやEthereumの技術を活用したオープンソースのツールやアプリケーションを開発することによって最先端の暗号研究と実社会での活用の溝を埋めることを目的に活動しています。

プロジェクトも数多く立ち上げられており、プロジェクト内容もHuman collaborationのためのツール、Data Provenance、開発者ツール、Research、Funding&Collaboration、Ecosystemなど多岐に渡ります。

具体的なプロジェクトはこちらのリンクから確認することができます。

2.Web3におけるプライバシーの課題について

Web3におけるプライバシーの課題として、個人情報・機密情報をチェーンに乗せることはできず、互いに秘匿性の高いデータを活用してトラストレスにスマートコントラクトを実行することが難しいという課題があります。解決策として、privacyなデータはonchainのトランザクションには載せないが認証することの仕組み、すなわちデータを隠した状態でデータに関する検証ができるとよく、その手段として暗号技術を活用します。

また、Web3上のシステムでは既存のシステムをトラストレスに活用することが難しいという課題があり、こちらは暗号技術を活用してトラストを最小化していく方法が取られています。

現在のフロー：

ユーザー → 個人情報をサーバーに送信 → サーバーで照合・検証(サーバーが正しく情報を管理するというトラストが必要)

ZKPを用いたフロー：

ユーザー → 証明のみをサーバーに送信 → サーバーは検証のみ実行(検証に対するトラストのみ)

3.暗号技術の紹介

特定の用途にデザインされた暗号プロトコルではなく、プログラム可能でGeneralの暗号プロトコルをProgrammable Cryptographyといいます。より暗号が複雑化している現代で、1つ1つ安全に特定の用途に特化して発明・実装するのは膨大な時間とコストがかかってしまいます。そこでプログラムのコードとして暗号を扱うことで暗号プロトコルとしての安全性はその理論に依拠し、機能の柔軟性はプログラムに依拠することで暗号プロトコルの発明・開発タスクを単純なプログラミングタスクへと変換されます。

Programmable Cryptographyを代表するものとして今回講演で取り上げていただいたのが、zkSNARKs、General-purpose MPC、FHEになります。

zkSNARKS(ゼロ知識証明)

zkSNRAKSはzero-knowldge(Inputの情報を明かさない)、Succinct(証明のサイズは小さく、検証のコストが小さい)、Non-interactive(ProverとVerifierはインタラクティブなやりとりを必要としない)、Argument of knowlege(命題が真となる値を実際に”知っている”ことをた公式時間の計算資源で証明・検証する)を意味します。

ある計算F(ハッシュの計算やTokenの送金処理)とPublic Input XとPrivate Input Wが与えられた時、

F(X, W)が正しく行われた証明(proof)をWを明かすことなく証明者(計算者)は証明することができ、また誰でも簡単に検証できます。

計算を実行する時に発生する状態遷移を変数に対する制約条件として数学的に記述して、入力X,W’と中間の値に対して制約条件が成り立つ時だけ検証をパスするようなProofを生成することができます。x = y + zのような制約条件を全て記述し、最終的にこの制約条件を全て満たしていることを証明できるデータがproofというイメージです。

ユースケースとしては、onchainのコントラクトで扱う情報の来歴証明(provenance)において、生データは公開したくないけど信じてほしい事実があるので、zkSNARKsを使ってこれらを数学的に小さいサイズで証明することができるため、Solidityなどのonchain verifierなどで実用されています。(zkRollupなど)

MPC(秘匿マルチパーティ計算)

MPCはn個の入力を取る計算F(X_1, …X_n)が与えられた際にn人の参加者がそれぞれの入力値X_iを互いに明かさずに計算の結果を得ることができる暗号プロトコルの総称です。

閾値署名というn人の参加者のうち、t人以上が協力しないと署名を生成できない仕組みなどで、活用されています。先ほど紹介したzkSNARKsで利用するパブリックパラメーターをセキュアに生成する方法としても活用されています。

AppleとGoogleも新型コロナの接触通知システムにMPCを採用するなど、web2の企業でも技術的に注目されています。(参考リンク)

ただし、ZKPと違い、MPCでは第三者が計算結果の検証をすることはできないため、onchainに結果を載せたりすることができないという問題があります。そこで、ZKPとMPCを掛け合わせたCollaborative zkSNARKsを活用し、MPCの結果に関して第三者が検証可能なSNARK proofを生成することができるようになります。

FHE(完全準同型暗号)

秘密の情報を暗号化した状態で任意の計算を実行できるようにする暗号化方式がFHEになります。これらを活用することで、互いの値を知らせることなく、暗号化したまま計算を行い、複合すると結果のみが帰ってくる形になります。

これは機械学習でプライベートなパラメータを学習データに扱う際や医療現場で、個別患者を開示せずに統計データのみを取得する際などへの活用機会が存在します。

AppleもFHE技術の一部を活用しており、知らない電話番号がかかってきた際に、その電話番号をAppleに知らせることなく、スパムかどうか判断する機能をiOS18から搭載しています。(参考リンク)

事例紹介

事例紹介1. Collaboration Tool:投票システム

Dカードでの認証&署名で市民だけが投票できるOnchainのデジタル投票システムを実現したいとします。そのまま実装してしまうと以下の2つの課題が発生します。

1. 投票データにIDカードで署名することで、検証時に公開鍵で照合すると、公開鍵に紐いたIDがわかってしまう。(匿名性の欠如)
2. 投票トランザクションに投票内容を含める必要があるため、各投票者の投票先がわかってしまう

1の課題を解決する手段として、zkSNARKsを使用することができます。特にPSEチームが開発しているsemaphore(https://semaphore.pse.dev/)を活用すれば、自分のIDを明かさずにあるグループに所属していることを証明することができます。”投票権を持つ市民”というグループを作成して、そこに属しているproofを生成することができれば自分が誰なのかを明かすことなく投票を行うことができます。

2の課題を解決する手段として、MPCを活用して各票の内容が分からない状態で集計することができれば、各々の投票先を知らせず、結果だけを計算することが可能になります。ただし、MPCでは先に挙げた通り完全なトラストレスではないため、完全なトラストレスでプライバシーも保護することのできる投票システムを実現するには、iO(indistinguishable Obfuscation)という技術が必要になると考えられており、実現はまだ先です。

事例紹介2. Data Provanance:TLSNotary

Web2のデータをonchainでトラストレスに活用したいことを考えた時に、現状のTLS(オンターネットの通信プロトコル)だとトラストレスにオンチェーンにデータを持ってくることは難しく、AliceがサーバーからTLSで受け取ったデータをBobに渡す際にALiceは自由にデータを書き換えてしまうことができ、Bobはそれを検証することができません。

現在は解決策として、データを安全にポートするOAuthというサードパーティアプリケーションに対して、ユーザーへのリソースへの制限付きアクセスを許可するフレームワークが活用されています。これにより、Aliceはデータを書き換えることができませんが、OAuthは全てのデータを閲覧することができるため、今度はOAuthに対するトラストが発生します。

そこで、さらなる解決策として考えられているのが、TLSNotrayです。AliceとBobでTLSのマスターシークレットを鍵分割し、TLSの通信がAliceからBobに行われた際に2人でMPCを実行することで、TLSの通信内容の証明が完了します。onchainでの活用も可能です。