zk-SNARKsは、ブロックチェーンと非ブロックチェーンベースのアプリケーションの両方でますます不可欠な部分になっている強力な暗号化ツールです。 その複雑さは、それらがどのように機能するかを理解することと、それらを効果的に利用する方法の両方において明らかです。 本稿では、zk-SNARKが現在のアプリケーションにどのように適応するかを掘り下げ、実現できることとできないことの例を示し、zk-SNARKが特定のアプリケーションに適している場合に関する一般的なガイドラインを提供します。 特に、プライバシーの確保における役割に重点が置かれます。

zk-SNARKsとは?

パブリック入力 x、プライベート入力 w、および入力を検証する (パブリック) 関数 f(x,w) → {True,False}があるとします。 zk-SNARKを使用すると、与えられたfとxに対してf(x,w)=真となるように、wが実際に何であるかを明らかにすることなく、wを知っていることを証明できます。 さらに、検証者は、たとえwを知っていたとしても、f(x,w)を計算するよりもはるかに速く証明を認証することができます。

これにより、zk-SNARKsにはプライバシーとスケーラビリティという2つの属性が与えられます。 前述のように、この記事の例では、主にプライバシーの側面に焦点を当てます。

会員であることの証明

イーサリアムウォレットを持っていて、このウォレットがプルーフ・オブ・ヒューマニティ・システムに登録されていることを証明したいが、登録された個人が実際に誰であるかを開示しないとします。 この関数は、数学的には次のように記述できます。

プライベート入力 (w): あなたのアドレス A、あなたのアドレスの秘密鍵 k

公開入力 (x): 検証済みのすべての Proof-of-humanity プロファイルのアドレス セット {H1…Hn}

検証関数 f(x,w):

w をペア (A, σ) として解釈し、x を有効なプロファイル リストとして解釈します {H1…Hn}

A が {H1…Hn} のアドレスの 1 つであることを確認します。

privtoaddr(k) = A を確認します。

両方の検証に合格した場合は、True を返します。 どれかが失敗した場合は、False を返します。

証明者は、アドレス A と関連するキー k を生成し、f のプライベート入力として w=(A,k) を提供します。 彼らは、チェーンから、検証済みの人道証明プロファイルの現在のセットである {H1…Hn}パブリックインプットを取得します。 次に、zk-SNARK証明アルゴリズムを実行し、(入力が正しいと仮定して)証明を生成します。 この証明は、検証済みプロファイルリストを取得したブロックの高さとともに検証者に送信されます。

また、検証者はチェーンを読み取り、証明者が指定された高さからリスト {H1…Hn} を取得し、証明を確認します。 検証が成功した場合、検証者は証明者が検証済みの人間性の証明プロファイルを持っていると信じます。

より複雑な例を掘り下げる前に、上記の例を完全に理解することを強くお勧めします。

会員証明の効率化

前述の証明システムの欠点の1つは、検証者がプロファイルセット {H1…Hn}全体を認識する必要があるため、このセットをzk-SNARKメカニズムに「入力」するのにO(n)時間が必要であることです。 この問題は、すべてのプロファイルを含むオンチェーンの Merkle ルートをパブリック入力 (場合によっては状態ルートのみ) として使用することで対処できます。 別のプライベート入力であるマークル証明Mを追加して、証明者のアカウントAがツリーの適切な部分にあることを確認します。

ZKメンバーシップ証明のマークル証明の非常に最近の、より効率的な代替手段はコーキングです。 将来的には、これらのユースケースの一部は、コーキングと同様のソリューションに移行する可能性があります。

ZK-SNARKとコイン

ZcashやTornado.cashなどのプロジェクトにより、プライバシーを保護する通貨を所有することができます。 さて、前述の「ZKの人間の証明」を利用できると思うかもしれませんが、それは人間のプロファイル証明へのアクセスを証明することではありません。それは、コインへのアクセスを証明することです。 ここに問題があります:私たちはプライバシーと二重支出の両方に同時に対処しなければなりません。 つまり、同じコインを2回使うべきではありません。

コインを持っている人は誰でも秘密の「s」を持っています。 「葉」L=hash(s,1)をローカルで計算し、チェーン上で公開され、状態N=hash(s,2)の一部となり、これを無効化者と呼びます。 状態はマークルツリーに格納されます。

コインを使うには、送信者はZK-SNARKを生成する必要があります。

• パブリック入力には、無効化子 N、現在または最近のマークルルート R、および新しいリーフ L' が含まれます (送信者に L'=hash(s',1) として渡されたシークレット s' を持つ受信者を対象としています)。

• プライベート入力は、秘密の s、リーフ L、およびマークル分岐 M で構成されます。

検証機能では、次の項目がチェックされます。

• M は有効なマークルの枝であり、L は R を根付かせる木の葉であることを証明し、R は現在の状態のマークルの根である。

• hash(s,1)=L および hash(s,2)=N です。

トランザクションには、無効化子 N と新しいリーフ L' が含まれています。 L'については実際には何も証明していませんが、取引中に第三者による変更を防ぐために、証明に「混合」されています。 トランザクションを検証するために、チェーンはZK-SNARKを検証し、Nが以前のトランザクションで使用されたかどうかを確認します。 成功すると、使用済みの無効化子のセットに N が追加され、再び使用できなくなります。 L' がマークル ツリーに追加されます。

ZK-SNARKsを使用して、L(コインが鋳造されたときにオンチェーンで表示される)とN(使用されたときに表示される)の2つの値をリンクし、どのLがどのNに接続されているかを明らかにしません。L と N のつながりは、それらを生成する秘密 s を知って初めて認識できます。 鋳造された各コインは1回使用できますが(各Lに対して有効なNは1つしかないため)、使用される特定のコインはいつでも隠されたままです。

これは、把握すべき重要なプリミティブです。 以下で説明する多くのメカニズムはこれに基づいていますが、目的はさまざまです。

任意の残高を持つコイン

上記は、任意の残高を持つコインに簡単に拡張できます。 私たちは「コイン」の概念を維持していますが、各コインには(プライベート)バランスがあります。 これを実現する簡単な方法は、各コインにリーフLだけでなく、暗号化された残高を使用してチェーンストレージを設定することです。 各トランザクションは2つのコインを消費し、2つの新しいコインを作成し、2つのペア(リーフ、暗号化された残高)を状態に追加します。 また、ZK-SNARKは、インプットバランスの合計がアウトプットバランスの合計と等しく、両方のアウトプットバランスが負でないことを確認します。

ZK サービス拒否対策

興味をそそるアンチDOSツール:簡単には作成できないオンチェーンIDがあると想像してください。それは、人間に証明されたプロファイルや32人のETHバリデーター、またはETH残高がゼロでないアカウントである可能性があります。 送信者がプロファイルを持っていることを証明するメッセージのみを受け入れることで、よりDOS耐性のあるピアツーピアネットワークを作成できます。 各プロファイルには、1 時間あたり最大 1000 件のメッセージが許可されます。 送信者が不正行為を行った場合、そのプロフィールはリストから削除されます。 しかし、プライバシーを確保するにはどうすればよいでしょうか?

まず、設定: k をユーザーの秘密鍵とし、A=privtoaddr(k) を対応するアドレスとします。 有効なアドレスのリストは公開されています(例:オンチェーンレジストリ)。 ここまでは、人体が証明できる例を反映しています:どのアドレスかは明かさずに、あるアドレスの秘密鍵を保持していることを証明する必要があります。 しかし、私たちが求めているのは、あなたがリストに載っているという証拠だけではありません。 リストに載っていることを証明できるが、証明を制限するプロトコルが必要です。

時間を期間に分割し、それぞれが 3.6 秒 (1 時間あたり 1000 ピリオドになります) にします。 私たちの目標は、各ユーザーが期間ごとに 1 つのメッセージのみを送信できるようにすることです。同じ期間に2つ送れば捕まります。 時折のバーストを可能にするために、最近の期間を使用できます。 したがって、ユーザーに 500 の未使用期間がある場合、一度に 500 件のメッセージを送信できます。

議定書

nullifiersを使用した基本バージョンから始めましょう。 ユーザーは (N = \text{hash}(k, e)) で nullifier を生成し、(k) はキー、(e) はエポック番号で、メッセージ (m) で公開します。 ZK-SNARK は (\text{hash}(m)) を難読化します。 このプロセスでは、(m) については何も検証されないため、証明は 1 つのメッセージに結び付けられます。 ユーザーが同じ nullifier を使用して 2 つの配達確認を 2 つの異なるメッセージにバインドすると、捕まるリスクがあります。

次に、より複雑なバージョンに移行します。 このシナリオでは、後続のプロトコルは、誰かが同じエポックを 2 回使用したかどうかを単に確認するのではなく、秘密鍵を明らかにします。 私たちの重要な手法は、「2つの点が線を決定する」という原則にかかっています。 ライン上の 1 つのポイントを明らかにすると、ほとんど開示されませんが、2 つのポイントを露出すると、ライン全体が明らかになります。

すべてのエポック (e) に対して、線 (L_e(x) = \text{hash}(k, e) \times x + k) を選択します。 直線の傾きは (\text{hash}(k, e))、y 切片は (k) で、どちらも一般には知られていません。 メッセージ (m) の証明書を生成するために、送信者は (y = L_e(\text{hash}(m)) = \text{hash}(k, e) \times \text{hash}(m) + k) と、(y) の計算が正確であることを示す ZK-SNARK 証明を提供します。

要約すると、ZK-SNARKは次のとおりです。

パブリック入力:

• ({A_1…A_n}): 有効なアカウントの一覧

• (M): 証明書によって検証されているメッセージ

• (E):証明書のエポック番号

• (Y):ライン機能の評価

プライベート入力:

• (K):秘密鍵

検証機能:

• ({A_1…A_n}) に (\text{privtoaddr}(k)) が存在するか確認する

• 確認 (y = \text{hash}(k, e) \times \text{hash}(m) + k)

しかし、誰かがエポックを 2 回使用した場合はどうなるでしょうか。 2 つの値 (m_1) と (m_2) と、証明書の値 (y_1 = \text{hash}(k, e) \times \text{hash}(m_1) + k) と (y_2 = \text{hash}(k, e) \times \text{hash}(m_2) + k) を明らかにします。 次に、これら 2 つのポイントを利用して、回線を回復し、その後、秘密鍵である y インターセプトを回復できます。

そのため、誰かがエポックを再利用すると、うっかり秘密鍵を全員に公開してしまいます。 状況によっては、資金の盗難に繋がったり、単に秘密鍵をブロードキャストしてスマートコントラクトに統合したりして、関連するアドレスが削除される可能性があります。

ブロックチェーンのピアツーピアネットワーク、チャットアプリ、および同様のシステムに適した、実行可能なオフチェーンの匿名サービス拒否対策システムは、プルーフ・オブ・ワークを必要としません。 RLNプロジェクトは基本的にこの概念に焦点を当てていますが、わずかな変更が加えられています(つまり、無効化子と2点線技術の両方を利用するため、エポックが再利用されるインスタンスの検出が簡単になります)。

ZKのネガティブな評判

完全な匿名性(恒久的な名前すらありません)を提供する4chanのようなオンラインフォーラムである0chanを確立することを想像してみてください。 このようなシステムには、システムルールに違反する投稿にフラグを立てるガバナンスDAOがあり、3ストライクメカニズムを導入することができます。

レピュテーションシステムは、肯定的または否定的なレピュテーションに対応できます。しかし、ネガティブな評判に対応するには、追加のインフラストラクチャが必要です。 これにより、ユーザーは、たとえそれが否定的であっても、すべてのレピュテーションデータを配達確認に組み込む必要があります。 私たちは主に、Unirep Socialが実装しようとしているものに類似した、この挑戦的なユースケースに焦点を当てます。

リンク先投稿:基礎知識

ZK-SNARKを添えて、投稿を含むチェーンにメッセージを送信することで、誰でも投稿できます。 このZK-SNARKは、(i)アカウント作成の許可を与える一意の外部IDを持っていること、または(ii)以前に特定の投稿を公開したことの証明として機能します。 具体的には、ZK-SNARKは次のように機能します。

パブリック入力:

• ヌリファイア、N

• 最新のブロックチェーン状態ルート、R

• 投稿コンテンツ(校正に「混合」して投稿にバインドし、計算は行いません)

プライベート入力:

• 秘密鍵 k

• 前の投稿で使用した外部 ID (アドレス A) または無効化子 Nprev

• 連鎖にAまたはNprevが含まれていることのマークル証明M、

• このアカウントを使用して公開した i 番目の投稿

検証機能:

1. M が有効なマークル分岐であることを確認し、(A または Nprev のいずれかが指定されている方) がルート R を持つ木の葉であることを証明します。

2. N = enc(i, k) (enc は暗号化関数 (AES など) であることを確認します。

3. i=0 の場合は A=privtoaddr(k) を検査し、そうでない場合は Nprev=enc(i−1,k) を検査します。

証明検証に加えて、このチェーンは、(i) R が実際に最近の状態ルートであること、および (ii) 無効化子 N が以前に使用されていないこともチェックします。 ここまでは、前述のプライバシー保護コインと似ていますが、新しいアカウントを「ミント」するプロセスを追加し、アカウントを別のキーに「送信」する機能を削除しました。 代わりに、すべての無効化子は元のキーを使用して生成されます。 ここでは、無効化を可逆的にするためにencを使用しています。 キーkがあれば、特定の無効化ツールをオンチェーンで復号化できます。結果がランダムなちんぷんかんぷんではなく有効なインデックスである場合(たとえば、dec(N) < 2^64をチェックできます)、キーkを使用して無効化子が生成されたことがわかります。

レピュテーションの追加:

このスキームでは、レピュテーションはオンチェーンで明示的です。 一部のスマートコントラクトにはaddReputationというメソッドがあり、投稿でリリースされた無効化と、加算または減算されるレピュテーションユニットの数を入力として受け取ります。

各投稿のオンチェーンに保存されるデータを拡張しました。 nullifier N だけを格納する代わりに、 {N, h¯, u¯} を格納します。

• h ̄ = hash(h, r) ここで、h は証明で参照される状態ルートのブロック高さを表します。

• u ̄ = hash(u, r) ここで、u はアカウントのレピュテーションスコアです (新しいアカウントの場合は 0 から始まります)。

ここでのRは、ブルートフォース検索によってhとuが見つからないようにするために追加されたランダムな値です。 暗号化用語では、R を追加すると、ハッシュは隠されたコミットメントになります。

投稿がルート R を使用し、 {N, h¯, u¯}を格納しているとします。 その証拠には、データを保存した以前の投稿へのリンク {Nprev, h¯prev, u¯prev}。 また、投稿の証明は、hprev と h の間に投稿されたすべてのレピュテーションエントリをトラバースする必要があります。 検証関数は、各ヌル化子 N に対して、ユーザーのキー k を使用して N を復号化します。 復号化によって有効なインデックスが出力された場合は、レピュテーションの更新が適用されます。 すべてのレピュテーション更新の合計が δ に等しい場合、u = uprev + δ であることが証明されます。

「3ストライクでアウト」ルールを導入したい場合、ZK-SNARKはu>-3も保証します。 担当者≥ 100 の投稿に特別な「高評価の投稿」タグを付けるルールが必要な場合は、それも可能です。

このシステムのスケーラビリティを強化するために、投稿とRCAの2種類のメッセージに分けることができます。 投稿はオフチェーンになりますが、過去1週間に作成されたRCAを指す必要があります。 RCAはオンチェーンであり、パブリッシャーの以前のRCA以降のすべてのレピュテーション更新をトラバースします。 このようにして、オンチェーンの負荷は、1週間に1回の投稿につき1回のトランザクションと、レピュテーションメッセージごとに1回のトランザクションに削減されます。

中央集権的な当事者に説明責任を負わせる

場合によっては、中央集権的な「オペレーター」でシステムを設計する必要があります。 その理由はさまざまで、スケーラビリティのためである場合もあれば、プライバシー、特にオペレーターが保持するデータのプライバシーのためである場合もあります。 例えば、MACIの強制耐性投票システムでは、有権者は中央集権的なオペレーターが保持する鍵で暗号化されたオンチェーンで投票を提出する必要があります。 このオペレーターは、すべてのオンチェーン投票を復号化し、集計し、最終結果を表示します。 彼らはZK-SNARKを使って、自分たちがやったことがすべて正確だったことを証明しています。 この複雑さは、強固なプライバシー(強制的抵抗として知られる)を確保するために重要です:ユーザーは、たとえ証明したくても、誰にも投票を証明することはできません。 ブロックチェーンとZK-SNARKのおかげで、オペレーターへの信頼レベルは最小限に抑えられています。 悪意のあるオペレーターは強制的な抵抗を破ることができますが、投票はブロックチェーンに投稿されるため、投票を検閲して不正行為を行うことはできません。 また、ZK-SNARKを提供しなければならないため、結果の計算を間違えてごまかすことはできません。

ZK-SNARKとMPCの組み合わせ

ZK-SNARKsのより高度な用途は、証明が必要で、入力が2つ以上の当事者に分散され、どの当事者にも他の当事者の入力について知られたくない計算です。 2 パーティのシナリオでは、文字化けした回線がプライバシー要件を満たす可能性があります。Nパーティの場合、より複雑なマルチパーティ計算プロトコルを使用できます。 ZK-SNARKは、これらのプロトコルと統合して、検証可能なマルチパーティ計算を行うことができます。 これにより、高度なレピュテーションシステムが可能になり、複数の参加者がプライベート入力に対して共同計算を実行できます。 これを効果的に達成するための数学は、まだ初期段階にあります。

非公開にできないものは何ですか?

ZK-SNARKsは、ユーザーがプライベートな状態を持つシステムを作成するのに非常に効果的です。 しかし、誰も知らないプライベートな状態を維持することはできません。 情報が証明されるためには、証明者がそれを平文で知っている必要があります。 Uniswapは、民営化が難しい例です。 Uniswapには、誰のものでもない流動性プロバイダー口座という中心的な論理的な「エンティティ」があり、すべてのUniswap取引はこの口座で行われます。 誰かがこの状態を証明するために平文で保持する必要があり、各トランザクションには積極的な関与が必要になるため、このアカウントの状態を隠すことはできません。 ZK-SNARKの文字化けした回路を使用して、Uniswapの集中型で安全なプライベートバージョンを作成することもできますが、メリットがコストを上回るかどうかは不明です。 コントラクトはユーザーに資産価格を知らせる必要があり、ブロックごとの価格シフトは取引活動を明らかにすることができます。 ブロックチェーンは国家情報をグローバル化でき、ZK-SNARKはそれを民営化することができますが、国家情報のグローバル化と民営化を同時に行う確実な方法はありません。

プリミティブをまとめる

上記のセクションでは、それ自体が強力であると同時に、他のアプリケーションのビルディングブロックとしても機能するツールの例を見てきました。 通貨に不可欠な無効化は、他のユースケースでも再登場するようになりました。 ネガティブなレピュテーションのセクションで使用される「強制リンク」手法は、幅広い用途があります。 これは、ユーザーの "プロファイル" が時間の経過とともに複雑に変化する多くのアプリで非常に効果的であり、プライバシーを保護しながらユーザーにシステム ルールに従うように強制する必要があります。 ユーザーは、完全なプライベートマークルツリーを使用して内部の「状態」を表すことさえできます。 前述の「コミットメントプール」ツールは、ZK-SNARKで構築できます。 特定のアプリがオンチェーンで完全に機能せず、中央集権的なオペレーターが必要な場合でも、まったく同じ手法でオペレーターの誠実さを保つことができます。 ZK-SNARKは、説明責任とプライバシーの利点を融合させた強力なツールです。 制限はありますが、場合によっては、巧妙なアプリケーション設計によってこれらの制約を回避できます。 今後数年間で、より多くのアプリケーションがZK-SNARKを採用し、最終的にはZK-SNARKを他の形式の暗号化と融合させたアプリケーションが構築されることを期待しています。

免責事項：

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