前回、取引所に入金（送金）したとき、アドレスをコピーしたあとメモを2回また確認しました。コインが届いても自分のものとして認識されないのが怖かったので。後で@Dusk の取引所向け統合ドキュメントを見て、Duskは「正しいメモを入れる」よりもさらに厳密に入金バックエンドを要求していることに気づきました。まずMoonlightの公開アカウントモデルを選び、そのうえで「1人1アカウントにする」のか「共用アカウントにし、メモを使う」のかを決めるのです。

共用アカウントを採用する場合、メモは「このお金は誰のものとして扱うべきか」をシステムに伝えるだけの役割で、重複入金を防ぐ唯一の根拠として使うのには向いていません。2人のユーザーが同じメモを誤って入力する可能性がありますし、同一のデータでもバックエンドの再起動によって再スキャンされることがあります。公式ドキュメントでは、Duskの取引IDをidempotency key（重複を許さないキー）として使うことが推奨されています。平たく言えば、各入金に対して「1回しか記録されない」ロックをかけるようなものです。#dusk

もう1つ見落とされがちな境界があります。取引所はMoonlightの残高が増えたのを見てすぐにユーザーへ加算してはいけない、という点です。必要なのは、最終確定されたアーカイブ履歴から直接転送をスキャンすることです。そしてメモの欠落、形式エラー、未知のメモ、あるいは重複した入金は隔離領域に入れ、思い込みで自動的に入金処理しないこと。

さらに細かく言うと、バックエンドは「入金記録の書き込み」と「ブロック・チェックポイントの進行」を同一のデータベース・トランザクション内で完了させる必要があります。先にチェックポイントを進めてから入金を記録し、その間にサービスがクラッシュすると、ユーザーの金額がスキップされる可能性があります。逆に、先に入金だけ記録して進捗（チェックポイント）を保存しない場合、再スキャン時に同じ処理を2回扱ってしまう可能性があります。Phoenixへの変換、コントラクト支払い、質押（ステーキング）からの出金も、それぞれイベントルールを別々に設定し、通常の入金と混ぜてはいけません。

このロジックは宅配倉庫にすごく似ています。メモは宛名ラベル、取引IDは重複しない伝票番号、finalizedはその荷物が本当に倉庫に入庫された証拠です。どれか1つだけを見てしまうと、荷物の取りこぼしや、配達の重複につながることがあります。

だから私は$DUSK の取引所適応を見るとき、「入金・出金ができるか」だけでなく、最終確定後に入金処理まで確実に行えるか、取引IDの重複排除ができるか、チェックポイントと台帳の同期したコミットができるかを重視しています。本当に金融レベルの体験とは、フロントで回るだけの速さではなく、バックエンドの再起動や再スキャンでもユーザーに対して1円たりとも「多く」も「少なく」もならないことです。#dusk