PLONK：「“重計算”することなく、正しいかどうかを確認できる」
ここ数日またPLONKを見直したら、私の理解が少しだけはっきりしてきました。PLONKは検証を速くするためのものではなく、「全ネットワークでの再検証（全網重算検証）」のステップそのものを、仕組みの上で取り除くものだということです。
以前のオンチェーン検証は分かりやすいものでした：
あなたが一度計算し、私も一度計算して、結果が一致すれば正しい、というやり方です。
しかし、計算が複雑になった途端、ネットワーク全体が同じロジックを何度も繰り返し実行することになり、そのコストは線形に膨らんでしまいます。
PLONKがやっているのは、検証のための別の検証パラダイムへの切り替えです：
検証者に計算をやり直させるのではなく、証明者が「ゼロ知識証明」を生成し、検証者はその証明が成立しているかを確認するだけにします。
ここでの中核となる暗号学的ツールは KZG 多項式コミットメント（多項式の約束）です。
より厳密に言うと、PLONKは回路の制約を多項式制約のシステムに変換し、KZGコミットメントによってそれらの多項式を「結びつけ」ます。
証明者が提出するのは、これらの多項式が特定の点で一致していることの証明であって、計算の全トレース（軌跡）をそのまま見せることではありません。
検証者は計算過程を展開する必要はなく、楕円曲線上での少量のペアリング（pairing）演算だけで、これらの多項式関係が成立しているかを検証できます。
より身近で、しかし歪めないたとえとしては：
計算全体のプロセスを見ずに、ただ「数学的な署名」がルールに一致しているかどうかだけを確認するようなものです。この署名は適当に作れるものではなく、計算過程全体が多項式制約によって圧縮されて生成されます。
つまりPLONKのロジックはこうです：
以前は「重計算して、間違っていないことを確認する」
今は「計算によって生成された証明が成立するかを検証する」
さらに重要なポイントとして、前処理（preprocessing）メカニズムがあります。
PLONKは、回路のうち構造に関係する固定部分を、事前に汎用パラメータ（universal setup）として生成しておきます。検証時には、具体的な入力に関連する witness（ワーサット）部分だけを扱うため、回路制約の再構築を避けられます。
これをDuskのCVMに置き換えるとこうです：
コントラクトの実行が完了した後、完全な実行過程を公開する代わりに、zk-SNARKの証明を生成します。検証者は実行をやり直す必要はなく、その証明を検証するだけで結果の正しさを確認できます。
本質的な変化は、より正確には「冗長な計算に基づくコンセンサス検証」から、「多項式コミットメントに基づく検証可能な計算」へと移行した、と表現できます。
@Dusk $DUSK #dusk
ここ数日またPLONKを見直したら、私の理解が少しだけはっきりしてきました。PLONKは検証を速くするためのものではなく、「全ネットワークでの再検証（全網重算検証）」のステップそのものを、仕組みの上で取り除くものだということです。
以前のオンチェーン検証は分かりやすいものでした：
あなたが一度計算し、私も一度計算して、結果が一致すれば正しい、というやり方です。
しかし、計算が複雑になった途端、ネットワーク全体が同じロジックを何度も繰り返し実行することになり、そのコストは線形に膨らんでしまいます。
PLONKがやっているのは、検証のための別の検証パラダイムへの切り替えです：
検証者に計算をやり直させるのではなく、証明者が「ゼロ知識証明」を生成し、検証者はその証明が成立しているかを確認するだけにします。
ここでの中核となる暗号学的ツールは KZG 多項式コミットメント（多項式の約束）です。
より厳密に言うと、PLONKは回路の制約を多項式制約のシステムに変換し、KZGコミットメントによってそれらの多項式を「結びつけ」ます。
証明者が提出するのは、これらの多項式が特定の点で一致していることの証明であって、計算の全トレース（軌跡）をそのまま見せることではありません。
検証者は計算過程を展開する必要はなく、楕円曲線上での少量のペアリング（pairing）演算だけで、これらの多項式関係が成立しているかを検証できます。
より身近で、しかし歪めないたとえとしては：
計算全体のプロセスを見ずに、ただ「数学的な署名」がルールに一致しているかどうかだけを確認するようなものです。この署名は適当に作れるものではなく、計算過程全体が多項式制約によって圧縮されて生成されます。
つまりPLONKのロジックはこうです：
以前は「重計算して、間違っていないことを確認する」
今は「計算によって生成された証明が成立するかを検証する」
さらに重要なポイントとして、前処理（preprocessing）メカニズムがあります。
PLONKは、回路のうち構造に関係する固定部分を、事前に汎用パラメータ（universal setup）として生成しておきます。検証時には、具体的な入力に関連する witness（ワーサット）部分だけを扱うため、回路制約の再構築を避けられます。
これをDuskのCVMに置き換えるとこうです：
コントラクトの実行が完了した後、完全な実行過程を公開する代わりに、zk-SNARKの証明を生成します。検証者は実行をやり直す必要はなく、その証明を検証するだけで結果の正しさを確認できます。
本質的な変化は、より正確には「冗長な計算に基づくコンセンサス検証」から、「多項式コミットメントに基づく検証可能な計算」へと移行した、と表現できます。
@Dusk $DUSK #dusk