#dusk $DUSK @Dusk
信頼できるセットアップは1つの証明システムだけに必要で、もう一方はそれをスキップするだけだと私は思っていました。ですが、それは実際には違っていて、Dusk自身のセットアップがそれをはっきり示してくれました。
要点はこれです。PlonK も Groth16 も、どちらも信頼できるセットアップが必要です。Dusk は両方を Piecrust エンジンに組み込んだネイティブ関数としてサポートしています。違いは「必要かどうか」ではなく「どれくらいの頻度か」です。
Groth16 は、すべての回路ごとに新しいセットアップが必要です。新しいコントラクトロジック 新しいセットアップ そのたびに。これは組織立てるのにコストがかかりますが、その代わり支払うのは小さな証明で、検証は速いです。
PlonK はやり方が違います。1つのセットアップを1回だけ行い、その後に作る任意の回路で使い回します。こちらの方がはるかに柔軟です。しかし証明は大きくなり、検証にかかるコストも上がります。
つまり Dusk はここで「どちらか一方が勝ち」という選択をしているわけではありません。開発者に両方の道具を用意し、トレードオフを自分で選べるようにしているのです。速度が欲しくて、回路ごとにセットアップ作業を組み直すのを気にしない? それなら Groth16。柔軟性が必要で、より大きな証明を受け入れられる? それなら PlonK。
以前は、信頼できるセットアップは「必要か不要か」という二択の問題だと思っていました。Dusk のドキュメントを見て、それは本当は「どれだけセットアップ作業をやり直す用意があるか」と「どれだけ大きい証明を運ぶ覚悟があるか」という問題なんだと分かりました。
信頼できるセットアップは1つの証明システムだけに必要で、もう一方はそれをスキップするだけだと私は思っていました。ですが、それは実際には違っていて、Dusk自身のセットアップがそれをはっきり示してくれました。
要点はこれです。PlonK も Groth16 も、どちらも信頼できるセットアップが必要です。Dusk は両方を Piecrust エンジンに組み込んだネイティブ関数としてサポートしています。違いは「必要かどうか」ではなく「どれくらいの頻度か」です。
Groth16 は、すべての回路ごとに新しいセットアップが必要です。新しいコントラクトロジック 新しいセットアップ そのたびに。これは組織立てるのにコストがかかりますが、その代わり支払うのは小さな証明で、検証は速いです。
PlonK はやり方が違います。1つのセットアップを1回だけ行い、その後に作る任意の回路で使い回します。こちらの方がはるかに柔軟です。しかし証明は大きくなり、検証にかかるコストも上がります。
つまり Dusk はここで「どちらか一方が勝ち」という選択をしているわけではありません。開発者に両方の道具を用意し、トレードオフを自分で選べるようにしているのです。速度が欲しくて、回路ごとにセットアップ作業を組み直すのを気にしない? それなら Groth16。柔軟性が必要で、より大きな証明を受け入れられる? それなら PlonK。
以前は、信頼できるセットアップは「必要か不要か」という二択の問題だと思っていました。Dusk のドキュメントを見て、それは本当は「どれだけセットアップ作業をやり直す用意があるか」と「どれだけ大きい証明を運ぶ覚悟があるか」という問題なんだと分かりました。