昨夜、私はDuskのドキュメントを読み返し、技術的な主張よりも設計上の問いに惹かれる気持ちが強くなりました。
最初に腑に落ちたのは、MoonlightとPhoenixの分かれ方です。Moonlightはアカウントベースで、公的鍵、nonce、残高を持ちます。一方Phoenixは、メルクルツリーの中に「notes（ノート）」としてUTXOを使用します。Moonlightのトランザクション項目には、from、to、value、nonce、deposit、data、gas_limit、gas_price、signatureが含まれ、最大ガスはgas_limit × gas_priceで計算されます。
Phoenixはさらに面白いです。Jubjub曲線を使い、公的鍵（A,B）、秘密鍵（a,b）、ビューキー（a,B）があります。ノート構造には、type、com、enc、npk、R、encsenderが含まれます。一度限りのノート鍵はnpk = H(rA)G + Bとして導出され、支払い（spending）鍵はnsk = H(aR) + bとなります。
私はいまだに、ZK証明生成と委譲されたスキャンに関する信頼境界を理解しきれていません。ドキュメントでは、第三者がビューキーを使って証明を生成したり、支払権限を得ずにスキャンしたりできると述べていますが、どこが失敗ポイントになるのでしょうか？
さらに、nullifier（無効化子）、最近のメルクルルート、そしてガスが証明の内部で処理される場合、敵対的なネットワーク状況ではどのように振る舞うのでしょうか？ どの部分が分散化されており、ユーザーが精査すべき前提はどこにありますか？
#dusk $DUSK @Dusk
最初に腑に落ちたのは、MoonlightとPhoenixの分かれ方です。Moonlightはアカウントベースで、公的鍵、nonce、残高を持ちます。一方Phoenixは、メルクルツリーの中に「notes（ノート）」としてUTXOを使用します。Moonlightのトランザクション項目には、from、to、value、nonce、deposit、data、gas_limit、gas_price、signatureが含まれ、最大ガスはgas_limit × gas_priceで計算されます。
Phoenixはさらに面白いです。Jubjub曲線を使い、公的鍵（A,B）、秘密鍵（a,b）、ビューキー（a,B）があります。ノート構造には、type、com、enc、npk、R、encsenderが含まれます。一度限りのノート鍵はnpk = H(rA)G + Bとして導出され、支払い（spending）鍵はnsk = H(aR) + bとなります。
私はいまだに、ZK証明生成と委譲されたスキャンに関する信頼境界を理解しきれていません。ドキュメントでは、第三者がビューキーを使って証明を生成したり、支払権限を得ずにスキャンしたりできると述べていますが、どこが失敗ポイントになるのでしょうか？
さらに、nullifier（無効化子）、最近のメルクルルート、そしてガスが証明の内部で処理される場合、敵対的なネットワーク状況ではどのように振る舞うのでしょうか？ どの部分が分散化されており、ユーザーが精査すべき前提はどこにありますか？
#dusk $DUSK @Dusk