Duskの透明なトランザクションモデルを眺めていて、最初は「ほとんど基本すぎる」ように聞こえたあるものを見落としていました。それがnonceです。

MoonlightはDuskの口座ベースのトランザクションモデルです。各口座には公開鍵、残高、そしてnonceがあります。nonceは、その口座から送信されるトランザクションのカウンタとして機能します。

この小さなカウンタは、最初に思えるよりもずっと大きな役割を担っています。

ホワイトペーパーでは、nonceがリプレイ保護に明確に結び付けられています。署名が有効だからといって、それだけでトランザクションが許可されるわけではありません。口座のトランザクションのシーケンスもまた筋が通っていなければならないのです。

これは、正しく動いているときにはユーザーがほとんど気づかない種類のブロックチェーン基盤です。

トランザクションに署名し、ネットワークが処理して、残高が変わり、次へ進むだけ。
しかし、古い有効なトランザクションが再び受け入れられてしまうのを防ぐ仕組みがなければ、同じ認可が、まったく別のセキュリティ問題に化けてしまう可能性があります。
Duskで面白いのは、MoonlightとPhoenixが、非常に異なるモデルを通じて同じ根本的なトランザクション要件を満たしている点です。

Moonlightは、口座の状態、残高、トランザクションのメタデータを公開します。Phoenixは、残高の検証と二重支出の保護を、ZK証明とnullifierへと移します。それでも、どちらも所有権を確立し、不変性（malleability）を防ぎ、二重支出を止める必要があります。

つまり、本当の設計上の判断は「公開か非公開か」という単純な話ではありません。

ネットワークが直接検証できる状態遷移の割合をどれくらいにするか、それともどれくらいを暗号的に証明しなければならないか——そのバランスの問題です。
そう考えると、素朴なnonceは思った以上に興味深いものになります。

可視化されたトランザクションは表面にすぎません。その下には、同じ認可が単にリプレイされることができないようにするための一連のルールが集まっています。

実際に「ブロックチェーンの機能」のうち、見えないままのセキュリティ前提になっていて、失敗したときにだけユーザーが気づくものはどれくらいあるのでしょうか？

@Dusk $DUSK #dusk