元のソース:副題
概要
概要
ブロックチェーンシステムの動作原理を研究する場合、ビットコインやイーサリアムシステムの署名とアカウントの検証に使用される曲線および非対称署名アルゴリズムであるsecp 256 k 1 など、さまざまな暗号化の知識を知る必要があります。たとえば、sha 256 は、可変長情報を固定長コードに圧縮するために使用されるハッシュ アルゴリズムです。 Base 58 など、情報エンコーディングを印刷可能な文字で表される文字列に変換できます。たとえば、Diffie-Hellman 鍵交換アルゴリズムである ECDH は、P2P ノード間で通信鍵を安全に交換するために使用されます。
ZKP は 1985 年に初めて提案されました。しかし、長い間大規模な適用シナリオが見つかっていないため、技術の開発は非常に遅れています。 2009 年にビットコインが誕生するまで、ビットコインがブロックチェーンにおけるプライバシーとスケーラビリティの問題を解決するのに非常に適していることがわかり、それ以来、このテクノロジーの開発とエンジニアリング応用に多くの資本と人材が投資されてきました。 ZKP には Groth 16、PlonK、STARK などの実装が多数ありますが、これまでのところ実際の業界標準は登場していません。この記事では、さまざまな ZKP 実装の技術的特徴を概観し、お客様の役に立つことを願っています。研究、研究および工学開発。
ZKP適用分野
副題
1. プライバシー証明書
Tornado Cash は、イーサリアム上で動作するコイン ミキサーです。マークル ツリー上のノードを証明するために ZKP を使用します。ユーザーは、一定量のトークンを資金プールに入金し、ZKP によって生成されたプルーフを使用して、入金したことを証明できます。ただし、入金時に取引情報を開示する必要はありません。
副題
2. コンピューティングのアウトソーシング
zksync 1.0 は良い例です. イーサリアム トークンの転送とトランザクションをオフチェーンで実行し、その結果をノードに送信します. ZKP 証明を検証することで、ノードはそれが主張する方法に従って計算されているかどうかを知ることができます。
副題
3. データ圧縮
別の例として、Mina があります。多くの高速ブロックチェーン システムでは、トランザクション データが非常に大きくなります。システムは、コンセンサス プロトコルの検証のためにすべてのブロックを保持する必要があります。そのため、システムには、ハードウェアと永続的なストレージに対する非常に高い要件が必要になります。これは、ブロック チェーン ノードがディスク容量とデータ インデックス作成機能を継続的に増やす必要があることを意味します。現時点では、ZKP を使用して検証データを圧縮することができ、Mina は再帰的ゼロ知識証明によって台帳を 11 KB に圧縮しますが、それでもブロックの正確性を検証できます。
最初のレベルのタイトル
証明システムは ZKP の基礎となるアルゴリズム実装であり、対話型と非対話型の 2 つのタイプに分類できます。
副題
1. インタラクティブな証明システム
インタラクティブ証明システムは、証明者 (略して P) と検証者 (略して V) と呼ばれる 2 つの当事者で構成され、P は特定の秘密 (公開鍵暗号システムの秘密鍵や二次方程式の平方根など) を知っています。残基 x)、P は V に秘密を持っていることを納得させたいと考えています。インタラクティブ証明は複数のラウンドで構成され、各ラウンドで、P と V は、相互に受信したメッセージと自身で計算した結果に基づいて、メッセージを相互に送信する必要がある場合があります。典型的な方法は、各ラウンドで V が P にクエリを送信し、P が V に応答することです。すべてのラウンドが実行された後、V は、P が各ラウンドで自身が送信した質問に正しく答えることができるかどうかに応じて、P の証明を受け入れるかどうかを決定します。
2. 非対話型証明システム
上記の対話型証明システムでは、P と V は相互作用せず、P から V に対して直接証明が生成され、V が直接証明を検証する方式であり、この種の証明システムは非対話型証明システム (NIZK) と呼ばれます。
ブロックチェーンで使用する証明システムは通常 NIZK で、ブロックチェーン内のノードは検証者 V、エンドユーザーまたは 2 層ネットワーク (レイヤー 2) は証明者 P です。
記事の最後にある参考リンク [1] では、過去 10 年間に公開された NIZK スキームとその特徴について説明します。
Bulletproofs
実際のエンジニアリングアプリケーションでは、主にパフォーマンスと汎用性に焦点を当てているため、いくつかの一般的な証明システムをより詳細に分類して比較します。記事の最後にある参考リンクを参照してください [2]。
特徴: 簡潔なプルーフサイズ、信頼できる設定は不要ですが、プルーフの生成と検証に時間がかかります。
SNARKs (Succinct Non-interactive ARguments of Knowledge)
代表作：Bulletproofs、Halo、Halo 2。
特徴：証明のサイズは簡潔で証明検証時間は比較的短いが、各回路を信頼する必要がある。
SNORKs (Succinct Non-interactive Oecumenical (Universal) aRguments of Knowledge)
代表プロジェクト：Groth16。
特徴: コンパクトなサイズ検証、すべての回路に必要な信頼できるセットアップは 1 つだけです。
STARKs (Succinct (Scalable) Transparent ARguments of Knowledge)
代表的なプロジェクト：Sonic、PlonK、Marlin、Plonky 2。
特徴: 証明は非常に大きく、信頼できる設定は必要なく、優れたスケーラビリティを備えています。
上記の分類は絶対的なものではありません。たとえば、Halo/Halo 2 プロジェクトでは、デザインの際に Plonk から多くのアイデアを借用しています。さらに、SNORK はすべて信頼できる設定を必要とするため、通常 SNARK に分類されます。
3. 性能比較
(記事末尾の参考リンク[3]を参照)
最初のレベルのタイトル
回路プログラミング
回路は ZKP システムのビジネス ロジックの実装であり、ZKP アプリケーションの開発には回路プログラミングが必要です。ZKP ロジック コードが「回路」と呼ばれるのはなぜですか?主に以下の理由が考えられます。
ZKP 証明のコードは、単純な制約付きの一連の式 R 1 CS に変換され、次にラグランジュ補間法を使用して巨大な多項式 QAP に変換され、最終的にゲート回路の形式で制約されます。
ハードウェア回路と同様に、コードのすべての分岐が一緒に実行されます。
ZKP アプリケーションを最初から実装するのに暗号化を使用する必要はありません。これらの基礎となる証明システムを実装した開発ライブラリが多数あります。ビジネス ロジックの実装だけに集中する必要があります。もちろん、ライブラリごとに抽象度が異なり、回路を記述する式を学習する必要があるものや、処理に応じてコードを定義するだけで簡単に実装できるものもあります。
副題
libsnark
1. よく使用される開発ライブラリ
一般的な証明システム、基本的な回路ライブラリ、および応用例は C++ 言語で実装されています。
プルーフシステム: BBFR 15、BCCT 12、BCCT 13、BCGT V1 3、BCIOP 13、BCT V1 4 a、BCT V1 4 b、CT V1 5、DFGK 14、Groth 16、GM 17、GGPR 13、PGHR 13。
gnark
リンク: https://github.com/scipr-lab/libsnark。
Go で実装された証明システムで、回路を設計するための高レベル API を提供します。
証明システム: Groth 16、PlonK。
bellman
リンク: https://github.com/consensys/gnark。
Rust で実装された証明システム。回路インターフェイス、インフラストラクチャ、およびブール値や数値抽象化などのいくつかの基本的な回路実装を提供します。
プルーフシステム: Groth 16。
snarkjs
リンク: https://github.com/zkcrypto/bellman。
Javascript と WASM で実装された証明システム。セットアップの信頼性、証明の生成、証明の検証に使用できます。 snarkjs は、iden 3 独自の circom コンパイラを使用して、DSL で定義された回路をコンパイルします。
証明システム: Groth 16、PlonK。
ethsnarks
リンク: https://github.com/iden3/snarkjs。
Python で実装されているため、Ethereum スマート コントラクトをバリデータとして使用して、ユーザーのブラウザでプルーフを生成できます。現在、プロジェクトの開発は活発ではないため、同じシナリオで Circom を使用する方が良い選択となる可能性があります。
プルーフシステム: Groth 16。
bulletproofs
リンク: https://github.com/HarryR/ethsnarks。
単一および集合範囲証明、強く型付けされたマルチパーティ計算、および任意のステートメントを証明するためのプログラム可能な制約システム API を備えた Rust で実装された証明システムが開発中です。
プルーフシステム: 防弾。
halo 2
リンク: https://github.com/dalek-cryptography/bulletproofs。
Rust 実装に基づく証明システム。ZCash チームによって保守されています。 Halo 2 は PLONKish に特化しており、算術演算における回路の表現方法を非常に直接制御できるため、高度に最適化された回路の作成に最適です。
リンク: https://github.com/zcash/halo 2.
副題
2. 開発プロセス
gnark を例として挙げると、一般的なワークフローは次のとおりです。
1) コードを使用して、解決すべき問題を説明します。
2) R1 CS 制約システムにコンパイルします。
3) R1CS で Proving key と Verify key を取得できるように設定します。
5) 検証者は Verify キーを使用して Proof を検証します。
回路プログラミング用の特殊言語
副題
Cairo
1. イーサリアムプラットフォームに基づく
Cairo は、ある計算が正しく実行されたことを一方が他方に証明できる、証明可能なプログラムを作成するためのプログラミング言語です。 Cairo および同様の証明システムを使用して、ブロックチェーンにスケーラビリティを提供できます。 StarkNet は、インフラストラクチャと StarkNet 契約の作成に Cairo プログラミング言語を使用しています。
プルーフシステム：STARK。
Zokrates
リンク: https://www.cairo-lang.org/docs/。
ZoKrates は DSL を使用して回路を記述し、一般的に使用されるいくつかの回路ライブラリを提供します。これは、高級言語でのプログラムの標準化から計算証明の生成、Solidity での証明の検証まで、DApps で検証可能な計算を使用するのに役立ちます。
プルーフシステム: GM 17、Groth 16、Marlin。
Circom
リンク: https://zokrates.github.io/。
Circom 言語は DSL を使用して回路を記述し、snarkjs と連携して、イーサリアム スマート コントラクトを検証者として使用してユーザーのブラウザーで証明を生成できます。
証明システム: Groth 16、PlonK。
Noir
リンク: https://iden 3.io/circom。
Aztec の Rust ベースのプライバシー プログラミング言語は、DSL を使用して回路を記述し、プライバシーを保護するゼロ知識回路の安全かつシームレスな構築を可能にします。
証明システム: PlonK。
zkEVM
リンク: https://noir-lang.org/index.html
現在、zkSync、Polygon、Scroll、Starkware などのチームが zkEVM の実現に取り組んでおり、大きな進歩を遂げています。
副題
zkApp (Mina)
2.パブリックチェーンプラットフォームに基づく
zkApps は、ゼロ知識証明を利用したミナ プロトコルのスマート コントラクトです。 zkApps は、オンチェーンで計算を実行し、変動するガス料金を使用する他のブロックチェーンとは異なり、生成されたゼロ知識証明をチェーンに送信してこの計算を検証するために固定料金のみを請求しながら、オフチェーンで任意の複雑な計算を実行できます。 zkApps は Typescript で書かれています。
証明システム: PlonK。
LEO (Aleo)
リンク: https://docs.minaprotocol.com/zkapps。
Leo は、プライベート アプリケーションの作成専用に構築された関数型の静的型付けプログラミング言語です。開発者向けに設計されており、Aleo ブロックチェーン上に直感的に構築でき、プライベートな分散エコシステムの基盤を提供します。
リンク: https://leo-lang.org/。
最初のレベルのタイトル
ZKP の一般的なセキュリティ問題
過去数年間、SlowMist セキュリティ チームは、ZKSwap、Zkdex、Zksafe などの多くのよく知られた ZKP 製品に対して回路とアプリケーションのセキュリティ監査を実施し、中リスクおよび高リスクの脆弱性を多数発見しました。より深い理解。 SlowMist セキュリティ チームが ZKP アプリケーション監査で発見した一般的なセキュリティ問題は次のとおりです。
信頼パラメータのリスク
zk-SNARK を使用するには、Common Reference String (CRS) と呼ばれる共通のパラメーターのセットが必要です。ただし、これらのパラメータの作成によりいくつかのプライベート パラメータも生成されるため、当事者がこれらのプライベート パラメータを取得すると、証拠を偽造することができます。
さらに、乱数のバックドアがないこと、またはプライベート パラメータが意図的に保存されていないことを確認するために、CRS の生成プロセスを監査する必要があります。 zk-SNORK を使用するには、構造化参照文字列 (SRS) が信頼できることを確認する必要もあります。
信頼できる構成段階でのセキュリティリスクは、セキュアなマルチパーティコンピューティング (MPC) を使用することで解決できます. MPC の特徴は、参加者が誠実に参加できる限り、このマルチパーティコンピューティングシステムを通じて得られる最終的な計算結果は次のとおりです。信頼できる。
静的コードのセキュリティ
この部分は主に、未チェックのパラメータ、未処理の戻り値、数値オーバーフロー、未チェック境界などの非標準コーディングによって引き起こされるセキュリティ問題が原因です。回路を作成するための言語が C/C++ である場合にもリスクがあります。メモリオーバーフローの可能性があります。
サプライチェーン攻撃のリスク
サプライ チェーンのリスクは主に、古いバージョンのウェアハウスなどの脆弱なコード ベースの使用によって発生します。通常、ZKP アプリケーションはクライアントまたは Web フロントエンドと組み合わせて使用する必要があり、この部分もさまざまな点でハッカーに対して脆弱です。
論理エラー
回路実装において最も起こりやすいエラーはロジックエラーであり、回路設計が要件を満たしているかどうかを要件書と合わせて確認する必要があります。
二重支出攻撃
間違った設計は二重支払い攻撃につながる可能性があります。たとえば、一部の ZKP ライブラリにはスケーラビリティのリスクがあります。攻撃者は既知のプルーフを使用して別のプルーフを生成できます。設計が不適切な場合は、二重支払い攻撃につながります。
偽造を証明する
有効な証明は ZKP によって解決される主要な問題であり、完全性と信頼性を保証します。つまり、「偽は真であることはできず、真は偽であることはできない」ため、回路が偽の証明を作成できる場合、通常は回路の抜け穴が原因です。プロジェクト関係者は、公的に監査された ZKP ライブラリを使用し、安定したリリース バージョンを使用することをお勧めします。
サイドチャネル攻撃
回路が適切に設計されていない場合、異なる個人情報は異なる計算特性を持つ可能性があり、攻撃者は公開入力または証明を通じて個人入力データを推測する可能性があります。
回路制約の失敗
不適切な回路式を使用すると、変数が制約されなくなる可能性があります。
特殊値攻撃
一部の特殊な入力値（0、null など）は、システムの検証ロジックをバイパスする場合があります。
プライバシー入力の推測
Tornado Cashのようなアプリケーションでは、入力情報が推測できると重大なプライバシー漏洩問題につながるため、入力データが推測できないように厳格な監査が必要となります。
一部のプロジェクトには特別な管理者権限が付与されている場合があり、その権限が不正に使用されると、プロジェクトの資金やユーザー資産が盗まれます。
スマートコントラクトのリスク
スマートコントラクトのリスク
最初のレベルのタイトル
要約する
要約する
最後に、ワンストップのデジタル資産セルフカストディサービスプロバイダーである Safeheron の専門的な技術的アドバイスに感謝します。
参考リンク：
[ 1 ]. https://en.wikipedia.org/wiki/Zero-knowledge_proof
[ 2 ]. https://github.com/matter-labs/awesome-zero-knowledge-proofs
[ 3 ].https://docs.google.com/presentation/d/1gfB6WZMvM9mmDKofFibIgsyYShdf0RV_Y8TLz3k1Ls0/edit
