#dusk $DUSK @Dusk
月光の取引ドキュメントには、多くの人が定型文のように扱うセクションがあります——ホワイトペーパーが正式に名付けている、完全なセキュリティ特性の一覧です。それは4つあり、最後のものは思ったよりも面白いです。

月光のセキュリティ特性：不可偽性（デジタル署名で担保される）、二重支出の防止（ネットワークが受理前に残高を確認する）、可変性の排除（署名が取引フィールドすべてのハッシュをカバーするため、何かを改変すれば無効になる）、リプレイ攻撃の防止（ナンスで担保される）。

そこで、ナンスがここで実際に何をしているのかを考えてみる価値があります。

リプレイ攻撃とは、誰かが正当な署名付き取引を取り込んで、そのまま再送することです。署名は本物です——あなたがそれに署名したのです——しかし、この特定の送信をあなたが許可したわけではありません。リプレイ防止の仕組みがないと、一度送信された有効な取引は、それを捕捉した誰にでもよって無期限に再送され得ます。

ナンスがそれを解決します。すべての月光アカウントには現在のナンスがあり、受理された取引ごとに増えるカウンターです。取引を送信するとき、ナンス欄には current_nonce + 1 を厳密に指定する必要があります。ネットワークは、そのチェックに失敗するものを拒否します。受理された後は、そのアカウントのナンスがインクリメントされるので、同じ取引は再送できません。

これが珍しいと言っているわけではありません。すべての本格的なアカウントベースのチェーンが、まさにこの目的のためにナンスを使っています。イーサリアムも同じやり方です。

ただし、これが単純だとも言いません。ナンスは署名とは別の役割を果たしています——署名が認可を証明し、ナンスが「この取引の具体的なインスタンスが新しいものである」ことを証明するのです。両方が必要で、そしてそれぞれ別の攻撃ベクトルをカバーしています。

未解決なのは、月光のナンスがアカウント単位なのか、それともコントラクト単位なのかという点です。同じアカウントからコントラクト呼び出しと直接送金を行うときに、共有のナンスカウンターが使われるのか、それとも各種類のやり取りごとに独自のシーケンスがあるのか——@Dusk
$DUSK #dusk