#dusk $DUSK 昨夜、ダスク・ホワイトペーパーの plonk のセクションを読み返していて、見落としていた何かに気づいた……

最初の2回通して読んでいたときには。

証明スキームは単に値を隠すだけではなく、「証明されるもの」と「開示されるもの」を分離する。公開入力は一方向へ、秘密のものはそのまま残る。

ロックされていて、検証者はその主張が真かどうかしか学ばない。

それが意味を持つためには、3つの性質が成り立つ必要がある：完全性（completeness）。健全性（soundness）。そして零知識（zero-knowledge）。

知識性（knowledgeness）を1つでも欠けば、プライバシーの主張は崩れ落ちる。

面白いのは、これは後付けでステート遷移関数にボルトで留められているわけではないことだ。

rusk vm にネイティブに組み込まれている。すべての実行経路は、計算自体を公開せずに「正しさの証明」を運べる。

契約ロジックが増えるにつれて、証明生成コストがどうスケールするのかを完全には解決できていない。

とはいえ複雑だ。そこが、ずっと行ったり来たりして考えている部分。

ここでの検証鍵（verifier key）のセットアップを掘り下げた人いる？

#dusk @Dusk $DUSK