Zcash
はじめに読むもの
MPC
Haloについて
Halo2
トランザクション周りの秘匿化
ZcashのOrchard poolは、ゼロ知識証明のためにHalo 2ライブラリを使用しています。
NU5アップグレード前、Zcashはzk-SNARK用のRust言語ライブラリであるbellmanを使用していました。
Saplingのアップグレード前は、ZcashはC++ライブラリのフォークであるlibsnarkを使用していました。
Zcashのzk-SNARKに使用されているプロトコルの詳細については、Saplingアップグレードまで使用されていたPinocchioプロトコル、および現在使用されているJens Grothのzk-SNARKについての論文を参照してください。
bitcoinのようにパブリックな情報を元にTxが検証されず、Tx作成者は以下のようなproofを作成することになる。
入力値の和が、各シールド転送の出力値になる。
送信者は、入力されたノートのspending key(private)を持っていることを証明し、支出する 権限を与える。
入力ノートのspending keyは、これらのプライベートキーを知らない当事者によってトランザクションが修正されないように、トランザクション全体の署名に暗号的にリンクされる。
さらに、シールド取引は、以下に説明する他のいくつかの条件を満たす必要がある。
ビットコインはUTXOを追跡して、どのトランザクションが支出可能かを判断します。Zcashでは、UTXOに相当するシールドは と呼ばれ、これを使用するには「nullifier」を公開する必要があります。
Zcashは、Merkle treeを使用したCommitment schemeを採用しており、同時にNullifierを使用して古い履歴を無効にすることによって、トランザクションのプライバシーを保護しています。
Commitment
Commitmentとは、Merkle treeと呼ばれるデータ構造を用いて、トランザクションの内容をハッシュ値に変換し、その値を公開することで、トランザクションの詳細情報を秘匿するための手段です。Zcashでは、Commitmentを使用して、トランザクションの送信者、受信者、および送信される金額を秘匿しています。
Nullifier
Nullifierは、過去に使用されたCommitmentを無効にするための値
トランザクションが送信されるたびに、新しいNullifierが生成され、過去に使用されたCommitmentと関連付けられます。
このため、誰かがNullifierを知っている場合でも、その値を使用して過去のトランザクションを追跡することはできません。
CommitmentとNullifierを使用することで、Zcashは、ユーザーがトランザクションの内容を公開せずに、同時にトランザクションの重複使用を防止することができます。これにより、Zcashは高いプライバシーを実現することができます。
Zcashのノードは、作成されたすべてのコミットメントと、公開されたすべてのヌリファイアのリストを保持しています。
コミットメントとヌリファイアはハッシュとして保存され、コミットメントに関する情報や、どのヌリファイアがどのコミットメントに関連しているかが開示されないようになっています。
Commitment = HASH(recipient address, amount, rho, r)
シールドされたトランザクションが使用されるとき、送信者はそのspending keyを使用して、使用されていない既存のコミットメントからの秘密のユニークナンバーのハッシュであるヌリファイア（「rho」）を公開し、自分がそれを使用する権限があることを証明するゼロ知識証明を提供します。
このハッシュは、ブロックチェーンの各ノードが保持する、使用済みトランザクションを追跡するヌリファイアのセットに既に含まれていてはならない。
Nullifier = HASH(spending key, rho)
シールドトランザクションのゼロ知識証明は、上記の条件に加えて、以下の主張が真であることを検証する：
各入力ノートに対して、明らかにされたコミットメントが存在する。
ヌリファイアとノートコミットメントは正しく計算される。
出力ノートのヌリファイアが他のノートのヌリファイアと衝突することは不可能である。
Zcash は、アドレスの管理に使用する支出鍵に加えて、証明の作成とチェックのために証明鍵と検証鍵のセットを使用します。これらの鍵は、前述の公開パラメータ式で生成され、Zcash ネットワークのすべての参加者の間で共有される。シールドされた取引ごとに、送信者は証明キーを使用して、入力が有効であることの証明を生成する。マイナーは、証明者の計算を検証キーでチェックすることで、シールドされた取引がコンセンサスルールに従っていることを確認します。Zcashの証明生成の設計では、証明者は前もって多くの作業を行う必要がありますが、検証は単純化されており、主要な計算作業は取引の作成者に委ねられます（このため、シールドされたZcash取引の作成には数秒かかり、取引が有効であることの検証にはミリ秒しかかかりません）。
Spending key Viewing key
Zcashにおける「Spending key（スペンディングキー）」と「Viewing key（ビューイングキー）」は、Zcashのプライバシーとセキュリティの仕組みに関連する重要な鍵です。
スペンディングキーは、Zcashのユーザーが所有する秘密鍵の一種です。この鍵は、Zcashアドレスに関連付けられており、そのアドレスに紐付いた資金を使用する権限を持ちます。スペンディングキーを保持することで、ユーザーはそのアドレスから資金を送金したり、他のアドレスに資金を送ることができます。スペンディングキーは、トランザクションの署名に使用され、資金の移動を承認するために必要です。
一方、ビューイングキーは、Zcashのトランザクション履歴や残高情報を表示するための鍵です。ビューイングキーを持っている人は、対応するアドレスのトランザクション履歴を閲覧したり、残高を確認したりすることができます。ただし、ビューイングキーを持っているだけでは、資金の移動や操作は行えません。ビューイングキーは、プライバシーを保護しながら、ユーザーが自身の資金の状態を確認できるようにするために使用されます。
重要な点として、スペンディングキーとビューイングキーは異なる鍵です。これにより、ユーザーはプライバシーを守りながら、資金の操作と表示を分離することができます。スペンディングキーは資金の操作に使用され、ビューイングキーはトランザクション履歴や残高情報の表示に使用されます。
ユーザーは、スペンディングキーとビューイングキーを適切に管理し、必要な場合には保護する必要があります。秘密鍵が漏洩したり紛失したりすると、資金の安全性に悪影響を及ぼす可能性があるため、慎重な取り扱いが必要です。
楕円曲線
ZCashでは、Zcash Improvement Proposal (ZIP) で定義されたSaplingおよびOrchardの2つのプロトコルが存在します。それぞれが異なる楕円曲線を使用しています。
Saplingプロトコルでは、楕円曲線"Jubjub"（ジュブジュブ）が使用されています。Jubjubは、BLS12-381と呼ばれるペアリングベースの楕円曲線を基に構築されています。この楕円曲線は、セキュリティと効率性のバランスを考慮して設計され、Saplingのトランザクションにおける暗号的な操作を担当しています。
Orchardプロトコルでは、楕円曲線"Pallas"（パラス）が使用されています。Pallasは、BLS12-377と呼ばれるペアリングベースの楕円曲線を基に構築されています。Pallasは、Orchardのトランザクションにおける暗号的な操作を担当しています。
これらの楕円曲線は、ZCashプロトコルにおけるプライバシーとセキュリティの実現に重要な役割を果たしています。
bls12-381ではない
これらは Halo2に依存している？
pedersen
pedersen hashを使う
kate(kzg)
ペアリングできる楕円曲線を使う
Pasta
Goldilocks
最悪pedersen commitmentだけ使えば良さそう
詳細仕様