取引票は誰にでも書ける

見知らぬ誰かが、あなたの名前を入れたオンチェーンの取引票を作れる。

資産、支払い、期限、決済権限者、そして両方の受取先ウォレットまで書き込める。作成時に、あなたの署名は要らない。

盗難事件の始まりに聞こえる。Solana Foundation の Delivery versus Payment プログラムでは、これは提案の始まりにすぎない。

レコードを作った時点では、取引対象のトークンは一つも動かない。作成者はあなたに資金を入れさせることも、あなたとして決済することもできない。危険なのは、ソフトウェアが「レコードが存在する」を「内容に合意した」と取り違える瞬間だ。

最終交換がアトミックでも、同意には検証の関門が要る。

最も安全なボタンは最後にある

Delivery versus Payment が解く問題は明確だ。両方のレッグに資金が入ると、指定された決済権限者が一つのトランザクションで資産と支払いを交換できる。両方が成功するか、全体が元に戻る。Solana DvP ガイド

最終段階の片渡しリスクは消える。しかし、最初に届いた取引票の正しさまでは証明しない。

CreateDvp は許可不要である。作成時に署名するのは rent を負担する payer だけで、取引当事者と決済権限者は署名しない。生成される SwapDvp アカウントは署名済み契約ではなく、確認待ちの指示書だ。固定コミットのソース

設計上の境界ははっきりしている。各当事者は別のトークン送付で自分のレッグに資金を入れ、決済権限者は別の命令で交換を完了する。作成を安価で開かれた操作にできるのは、その後の参加者が行動前に読むことを前提としているからだ。

アドレスはラベルであり、契約ではない

取引アカウントのアドレスは、決済権限者、両当事者、二つの mint、使い捨て nonce から導出される。経済条件はアカウントの中に保存される。金額、時間、受取先は保存データであり、アドレス自体はそれらを拘束しない。

この構造には柔軟性がある。同じ当事者とトークンで、条件の違う取引を何度も作れる。その一方で、想定したアドレスを導出できただけでは不十分になる。

資金を入れる前に、クライアントは三つの問いを分けて確認する必要がある。

第一に、本物の DvP レコードか。 アカウントが DvP プログラムに所有され、固定の 458 バイト構造を持つかを確認する。

第二に、目的のレコードか。 アドレスが、レコード内の権限者、当事者、mint、nonce と整合するかを確認する。

第三に、合意した取引か。 金額、時間枠、権限者、二つの受取先を、実際に承認した注文と照合する。

生成済みクライアントには、所有者、構造、アドレス導出を検査する checked reader がある。しかし、メール、注文システム、署名済み文書に書かれた商業条件までは知りようがない。最後の照合は統合側の責任になる。

資金拠出で提案が現実のリスクになる

重要な瞬間は、ごく普通の操作に見える。当事者は checked token transfer で自分のトークンをエスクローへ送る。その送付命令は、オフチェーン注文と取引レコードが一致するかを質問しない。指定されたエスクローアドレスへトークンを動かすだけだ。

したがって、安全制御は送付後の警告ではなく、トランザクションを組み立てる前に置く必要がある。

実用的な統合ゲートは小さくできる。

1. 信頼できる RPC 応答からレコードを取得する。
2. プログラム所有者、構造、導出アドレスを検証する。
3. 重要な全条件を承認済み注文と照合する。
4. トークンの移動に影響するプログラムと権限を確認する。
5. すべてが一致した場合だけ、資金拠出トランザクションを作る。

項目が欠ける、または異なる場合、クライアントは差分を見せて停止すべきだ。不明値をゼロに置き換えたり、見慣れたアドレスから同意を推測したり、一般的な「続行」ボタンで利用者を境界の向こうへ送ったりしてはいけない。

先に拒否経路を試す

最小で役立つ BUILD は、正常系のデモではない。二つの fixture だ。

Fixture A には、想定した当事者、金額、時間、受取先を入れる。Fixture B では、当事者と mint はそのままに、支払額や資産の受取先など重要項目を一つだけ変える。

検証器は資金拠出命令を作る前に A を受理し、B を拒否する。その後、項目を一つずつ変えて同じ試験を繰り返す。シリアライズしたアカウント fixture でも、実資産を使わない devnet レコードでも実施できる。正しい取引をチェーンが処理できると再確認するのではなく、誤った取引票をクライアントが止められると証明する試験だ。

私は取引を送信しておらず、デプロイ済みプログラムのビルドも再現していない。元の調査は公開された状態機械、監査、稼働中のプログラムアカウントを読み取り専用で追跡した。ここで示した fixture 試験は、統合チームが実行し、結果を記録すべき設計案である。

アトミック決済は最後のボタンを安全にする。優れたクライアントは、それより前の拒否を退屈で明確な日常動作にする。

取引票は誰にでも書ける。最初のトークンを入れる価値があるかは、あなたのソフトウェアが先に判断すべきだ。