@Dusk_Foundation 検証に失敗したフェニックスのゼロ知識証明で、実際に何が起きるのかを調べに行った。というのも、多くの説明は「証明がチェックされる」というところで止まってしまうからだ。
ダスクのアーキテクチャは、証明が同一の証明の中で特定の性質を示さなければならないことを裏づけている。つまり、消費されるノートの所有権、入力と出力にまたがる残高の整合性、そして二重支払いがないこと——これらをすべて同じ証明に符号化し、別々のサイドチェックで検証するのではない。$DUSK
重要なのはそこだ。これらの性質のうち1つでも満たされなければ、証明全体が一つの単位として失敗する。残高チェックは通るが、所有権が失敗しても静かに見逃されるような「部分点」の道はない。
実際に何を意味するのかも追った。拒否された証明は、取引がそもそも一切含まれないことを意味する。ランタイムはそれを救済したり、部分的に処理しようとはしない。取引はそのまま起きず、失敗した試みについて何も状態変化として記録されない。#dusk
ダスク自身の資料から確認できていないのは、失敗した証明が、ノード運用者が事後に検査できるような形でmempoolのログに痕跡を残すのか、それとも診断記録なしに破棄されるのか、という点だ。
次に確認したいのは、ダスクの現在のウォレットツールが、失敗した証明に対して特定の理由を表示するのか、それとも単に汎用的な拒否として扱われるのか、だ。どちらかで、実際に通らなかった取引をデバッグしている人にとっての意味合いが大きく違ってくる。
#dusk $DUSK @Dusk
ダスクのアーキテクチャは、証明が同一の証明の中で特定の性質を示さなければならないことを裏づけている。つまり、消費されるノートの所有権、入力と出力にまたがる残高の整合性、そして二重支払いがないこと——これらをすべて同じ証明に符号化し、別々のサイドチェックで検証するのではない。$DUSK
重要なのはそこだ。これらの性質のうち1つでも満たされなければ、証明全体が一つの単位として失敗する。残高チェックは通るが、所有権が失敗しても静かに見逃されるような「部分点」の道はない。
実際に何を意味するのかも追った。拒否された証明は、取引がそもそも一切含まれないことを意味する。ランタイムはそれを救済したり、部分的に処理しようとはしない。取引はそのまま起きず、失敗した試みについて何も状態変化として記録されない。#dusk
ダスク自身の資料から確認できていないのは、失敗した証明が、ノード運用者が事後に検査できるような形でmempoolのログに痕跡を残すのか、それとも診断記録なしに破棄されるのか、という点だ。
次に確認したいのは、ダスクの現在のウォレットツールが、失敗した証明に対して特定の理由を表示するのか、それとも単に汎用的な拒否として扱われるのか、だ。どちらかで、実際に通らなかった取引をデバッグしている人にとっての意味合いが大きく違ってくる。
#dusk $DUSK @Dusk