トランザクションのシミュレーション：署名する前に、それが何をするのかを見る
アドレスは合っている。金額も合っている。どちらも確認した。それでもそのトランザクションは、あなたが思っているものではない。
これは仮の話ではありません。慎重な人が関わった暗号資産の損失の多くは、ごく普通にこの形をしています。誰かに説き伏せられて見知らぬ相手に送金したのではありません。見えている部分はすべて正しく、結果だけがまったく別の場所にあるもの——トークンの支出許可の中、コントラクト呼び出しの中、百回は見たアドレスのたった一文字の中——を承認したのです。
シミュレーションとは、その隔たりを埋めようとする試みです。あなたの署名がそれを現実にしてしまう前に、トランザクションの中身ではなく効果を見せること。
あなたが意図したものと、署名しているものとの隔たり
トランザクションは文章ではありません。バイト列です。
そのバイト列が素朴な送金であれば、それが述べていることと実際に行うこととの隔たりは小さい。アドレス、金額、手数料。コントラクト呼び出しであれば、隔たりは途方もなく大きくなり得ます。approve は許可のように見えます。それは別のアドレスがあなたのトークンを動かせる継続的な権利であり、ERC-20 の規格のもとでは、その呼び出しのどこにも、いくらまで・いつまでという枠を課す義務はありません。一度だけ署名された一つの承認が、数か月後に空にされることがあります。
署名するときにあなたが見ている画面は、そのバイト列を文章に翻訳しなければなりません。その翻訳こそが攻撃面です。あなたの署名を欲しがっている者が翻訳を作るなら、そこには何とでも書けます。
予行演習であって、約束ではない
シミュレーションとは、トランザクションをブロードキャストせずに現在のチェーン状態に対して実行し、何が変わるのかを記録することです。
SSP Enterprise では、それは提案が作られたとき、まだ誰も署名していない時点で行われます。シミュレーションは提案のビルダーが生成したもの——受取人、金額、トークンのコントラクト、そして SSP 自身が組み立てた呼び出しデータ——から構築され、クライアントが差し出した生の署名済み hex から作られることは決してありません。読み取り専用で動きます。三つのエンジンが異なるチェーン系統を受け持ちます。
- EVM チェーンはノードに対して読み取り専用の呼び出しを実行し、その結果生じる残高の変化とデコードされた呼び出しを読み戻します。
- UTXO チェーンはノードをまったく必要としません。入力と出力はすでに分かっているので、前後の比較は選ばれたコインの上での算術であり、受取人は自分に戻るお釣りなのか、本当に外部なのかに分類されます。
- Solana はビルダーが生成した未署名トランザクションをデシリアライズし、ネットワーク自身の
simulateTransactionを署名検証オフで実行して、その結果から Vault のトークン残高を実行前後で読み取ります。
返ってくるのはプレビューです。各資産の残高が以前いくらで、以後いくらになるのか。そして——EVM では——その呼び出しが実際には何なのか、メソッドと引数へとデコードされた姿で。
二つのものではありません。保証ではない：チェーンの状態は動き、提案時に走らせたシミュレーションはその時点のチェーンの写真です。そして関門でもない。設計としてはそちらのほうが面白い半分であり、あとで戻ってきます。
伝える価値のある 14 のこと
数字しか出さないプレビューは、結局あなた自身に問題を見つけろと求めています。ですからプレビューには警告が伴い、それは 4 段階の深刻度で 14 種類あります。
承認——最も多くのウォレットを空にしてきた分類です。無制限、あるいは上限のない許可は「重大」。許可リストに載っていないアドレスへのゼロでない支出承認はすべて「高」。そしてコントラクトではなく個人が持つアカウントを承認することも「高」です。それを行う正当な理由が事実上存在しないからです。承認を使うのはコントラクトであって、人ではありません。
受取人——組織の連絡先にも Vault のホワイトリストにも載っていない受取人は印が付きます。あなたの Vault が一度も送ったことのない相手も同様です。どちらもそれ単体で誤りではありません。どちらも読み直す価値があります。
コントラクトのリスク——ソースが検証されていない宛先コントラクト、直近 7 日以内にデプロイされたもの、そもそもコントラクトへネイティブ価値を送ること、そしてプロバイダが明確に悪性と印を付けたあらゆるアドレス。
実行——シミュレーションでトランザクションが失敗して巻き戻ること。つまりオンチェーンでも失敗し、手数料を無駄にするということです。あるいはシミュレーションされた流出が、提案の掲げる金額と一致しないこと。Vault が画面の言うより多く、あるいは少なく失うということです。
劣化——そしてはっきりと名付けられた、シミュレーションが走れなかった場合。到達できないノードは「利用不可」を返します。沈黙でもなければ、でっち上げた健康証明でもありません。
これらの深刻度の区別は、数そのものより重要です。重大と高は、見た目どおりではおそらくないトランザクションの話です。中と情報は、いつもと違うトランザクションの話であり、正当なトランザクションも時にはいつもと違います。
アドレスポイズニング：慎重な人こそを打ち負かす攻撃
一つの警告は独立した節に値します。ほとんどのセキュリティ助言が勧めているまさにその習慣を、狙い撃ちにしているからです。
アドレスポイズニングはこう働きます。攻撃者は、あなたがすでに取引しているアドレスと先頭 6 文字・末尾 4 文字を共有するように仕立てたアドレスから、ごく少額あるいはゼロのトランザクションをあなたの Vault へ送ります。何も盗まれません。実のところ何も行われてすらいません。そのトランザクションは、そっくりのアドレスをあなたの履歴に登場させるためだけに存在します。
のちに——数日後、同じ取引先へまた支払うとき——あなたは打ち直す代わりに、慎重な人がそうするように、自分の取引履歴からアドレスをコピーします。そして慎重な人が確かめるように確かめます。最初の数文字、最後の数文字。どちらも一致します。真ん中は一致せず、お金が向かうのは真ん中です。
SSP は提案のすべての受取人を、Vault がすでに知っているアドレスと突き合わせます。人間の目が行うのとまったく同じ、接頭と接尾の比較によってです。そして、なりすまされているアドレスを名指しする重大警告を出します。同じ確認は受信履歴に対して逆方向にも走るので、汚染されたアドレスは、あなたが使おうとする瞬間ではなく、届いた時点で印が付きます。
SSP を一度も使わないとしてもこの攻撃を知っておくべき理由。ほかのあらゆるアドレス攻撃を止める確認の習慣こそが、この攻撃が破るために作られたものだからです。アドレスは丸ごと比べるか、さもなくば何も比べないか。
なぜ警告はサーバーで計算されるのか——そしてなぜそれでも何も止めないのか
警告の集合はサーバー側で決まり、真実の源はあなたの組織の連絡先と Vault のホワイトリストです。これは意図的です。何が許可済みに数えられるかをクライアントが決められるなら、侵害されたクライアントは、すべてが許可済みだと静かに決められてしまいます。
それでいて、そのどれもトランザクションを止められません。シミュレーションが署名やブロードキャストの条件になることは決してありません。エラーになった、タイムアウトした、ノードに届かなかったプロバイダは「利用不可」を返し、提案は完全に署名可能なまま残ります。サブシステム全体が障害から隔離されていて、プレビューの障害が提案を座礁させることは決してありません。
奇妙な選択に聞こえるでしょうから、理由をはっきり述べておきます。ブロックできるプレビューとは、ブロックさせられるプレビューです。ノードを落とすことでも、偽の重大を出させることでも、ソフトウェアが壊れる千通りのどれによってでも。助言のためのサービスが不調だという理由で動かせない資金は、あなたが部分的に失った資金です。お金を守るのはマルチシグのしきい値であり、シミュレーションは鍵を持つ人間に知らせるためにそこにあります。トランザクションを実際に止めているものは何かがこの議論の長い版です。
サーバーとあなたの端末の意見が食い違うとき
ここまではすべてサーバーの読みです。あなたの端末は自分自身の読みを行います。
SSP Wallet が署名すべき提案をあなたに見せるとき、それはバイト列を自分でデコードし、自分が見つけたものを表示します。サーバーの要約ではありません。そのうえで両者を比べます。サーバーのデコードした呼び出しが、端末の導いたものとは異なる受取人の集合を含意するなら、端末は自前の重大な不一致警告を出し、サーバーのプレビューを視覚的に格下げします。
権威を持つのは端末のデコードです。この確認は意図して保守的です。サーバーのシミュレーションが欠けている、あるいは保留中であることは劣化であって矛盾ではなく、矛盾としては報告されません。またサーバーがそもそもデコード済みの呼び出しを生成する EVM チェーンにのみ適用されます。UTXO チェーンでは比べる相手が存在せず、端末自身のデコードがただ単独で立ちます。
どのウォレットを使うにせよ、持ち帰る価値があるのはこの性質です。セカンドオピニオンが値を持つのは、それが一つ目を侵害したのと同じ行為では侵害され得ない場所から来ているときだけです。同じサーバーからの二つの要約は、一つの要約です。
リスク表示を、読み飛ばす癖をつけずに読む
警告は、壁紙になるまでは効きます。いくつかの習慣がそれを有用に保ちます。
まず深刻度を、それから詳細を読む。 重大と高は立ち止まる価値があります。新しい取引先への最初の支払いに付く中や情報の警告は、システムが正しく働いている証拠であって、心配の理由ではありません。
承認に関する警告はすべて全面停止として扱う。 送金は動かすと言ったものを動かします。承認はトランザクションより長生きする権利を与えます。継続的な許可を与えるつもりがなかったのなら、答えはノーです。
画面より端末を信じる。 両者が食い違うなら、あなたの手の中の電話こそ、攻撃者が別途侵害しなければならなかったはずのハードウェアの上で動いているものです。
「利用不可」を「問題なし」と読まない。 誰も確認していない、という意味です。それは自分でより注意深く見るべき理由であり、金額の大きい支払いやいつもと違う支払いでは特にそうです。
ここでの話はすべて署名の直前の瞬間についてです。そのあとに起きること——誰が署名できるのか、何人必要か、どの操作が再び 2 台の端末を求めるのか——は、はじめての企業向け Vault を設定すると重要な操作と再署名から始めてください。そしてこれらの警告が形づくられる元になった攻撃の型については、暗号資産ユーザーを狙うフィッシング攻撃が問題の人間の側の半分を扱っています。
