T26 · Cross-chain

現実の問題

Aチェーンの1,000 USDCを、Bチェーンのプロトコルで使うため橋を渡します。

二分後、財布にはUSDC 1000と表示されます。アイコン、名前、decimalsも正しく、担保にして借り入れます。

三週間後の深夜、A側の橋のロック契約が空になります。

B側のアドレス、残高、名前は変わりません。変わったのは、その1,000枚を裏付けるものがなくなったことだけです。

価格は数分で数セントへ落ち、担保は債務を下回ります。清算人も価値のない証書を受け取りたくなく、預金者が不良債務を分担します。

利用者は大手の橋を使い、馴染みの名前を確認しました。財布も価格サービスもUSDCと表示していました。

その1,000枚は、実際には何だったのでしょう？

思考実験

直接通信のない二つの国を考えます。

A国の倉庫へ貨物を預け、受取証をB国へ持っていき売ります。

Bの買い手はなぜ信じるのか？ Aの倉庫を直接確認できません。

方法は三つです。

第一、Bでも認められる公証人に頼みます。 Aを見た人の証言は安く速い反面、公証人次第です。買収、強要、偽造をBでは発見できません。

第二、B自身がAへ観測者を常駐させます。 入出庫を記録し、他人でなく自分の検証規則に頼ります。

代償は費用です。無関係な99%を含めすべて追跡し、複雑な規則には対応できないこともあります。

第三、受取証を渡しません。 Bに同じ貨物を持つ人と交換します。その人がAの在庫リスクを引き受け、料金を取ります。

ここが重要です。

三つとも貨物は一歩も動いていません。変わるのは、Aの所有権というメッセージをBがどう信じるかです。

受取証は貨物ではなくメッセージです。人がそれを資産として解釈するから価値を持ちます。

メッセージが偽物なら、解釈された資産は最初から存在しません。

冒頭のUSDCは解釈結果です。ロックが空になった時点で根拠もなくなりました。

あなたが決める

アプリに橋を選ぶ前に、検証方法を選びます。

結果を観察する

四つを比較します。

二列目から次が分かります。

無信頼のクロスチェーンはなく、信頼先の選択があります。

trustlessという宣伝は、誰が不正なら自分の資金が失われるかへ翻訳します。できなければ理解不足です。

橋に事故が多い理由もあります。

利用が増えるとロックは増えますが、安全予算は増えません。1,000万から10億になっても検証者は同じN人で、侵害費はほぼ同じです。

すると次へ近づきます。

侵害費が、侵害利益より小さくなります。

次章の経済攻撃の式です。橋は資金が集中し、一プールでなく全ロックが失われるため特に露骨です。

章の結論です。

渡るのはメッセージで、資産はその解釈の一つです。

1,000枚はAからの情報に基づきBでmintされた証書で、価値は情報の真実性への信頼に依存します。

モデルを作る

伝送・検証・解釈の三層

信頼仮定を決めるのは中間層です。

三層を分けると宣伝の多くを見抜けます。「独立relayが20ある」ことは伝送層で到着を保証するだけで、情報の真実性は保証しません。何人いても、保証するのは到着だけで、真実性ではありません。 問うべきは検証層の担当者です。

資産を表す三方式

同じ送金でも受け取るものは違います。

第一方式には見落としがあります。

同じ資産に複数の非互換版ができます。 五つの橋のUSDCは五アドレスで、互換ではありません。別の橋で償還できません。

流動性が分裂し、利用者は版を見分けにくくなります。

allowlistはsymbolでなくアドレスです。 名前で識別するコードはいずれ不適切な資産を受け入れます。

発行者自身のBurn-Mintは、すでに発行者を信頼しているなら橋という追加仮定を減らせます。

メッセージの冪等性と再送

T17 のoutboxと同じ二性質が必要です。

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.4;

contract MessageReceiver {
    // 実行済みメッセージ。全体で一意な座標をキーにする
    mapping(bytes32 => bool) public executed;

    event Executed(bytes32 indexed id);

    function execute(
        uint256 srcChainId,
        uint256 nonce,
        address sender,
        bytes calldata payload,
        bytes calldata proof
    ) external {
        // 1. 宛先チェーンを含め、多チェーンでの重複実行を防ぐ
        bytes32 id = keccak256(
            abi.encode(srcChainId, block.chainid, nonce, sender, payload)
        );

        // 2. 実行済みなら拒否
        require(!executed[id], "already executed");

        // 3. この検証が橋全体の安全を決める
        require(verify(id, proof), "invalid proof");

        // 4. 記録してから実行。逆順はreentrancy
        executed[id] = true;
        _apply(sender, payload);

        emit Executed(id);
    }

    function verify(bytes32, bytes calldata) internal view virtual returns (bool) {
        return false; // 具体的な検証層で実装
    }

    function _apply(address, bytes calldata) internal virtual {}
}

四つの注釈は実際の事故に対応します。

IDには宛先チェーンが必要です。 なければ一つの証拠で複数チェーンにmintできます。

冪等性はチェーン上の永続状態で実装します。 relayや利用者の再試行、再編で繰り返し届きます。T16 と同じく、根拠は記憶でなくメッセージ座標です。

検証の一行が橋全体の安全です。 実例で確認します。

記録が先、実行が後です。 逆順はreentrancyになります。

最終性の境界

T17 と同じ問題ですが、被害は大きくなります。

元側：ロック → inclusion → 複数確認 → 十分深い
宛先：           ↑
             どの時点でmintする？

直後にmintして元側が再編されると、mint済みなのに担保が存在しません。

無担保増発で、回収できません。

T17 の取り消せない動作は十分深くなってからという原則です。通知なら謝れますが、発行済み資産は取り消せません。

待機深度には二つの注意があります。

第一、待機深度はチェーンごとの設定で、全体共通の定数ではありません。 最終性は、明確に確定するchainと確率的保証だけのchainで大きく異なります。別chainの値をそのままコピーする誤りは、攻撃に利用されます。

待機と体験は衝突します。 三秒到着は深度を下げるか、立替人へリスクを移すか。後者は明示的、前者は全利用者へ隠れて移します。

攻撃面

橋は集中資金、複雑な検証、二つの安全モデルを持ちます。

実際の攻撃面です。

通用メッセージはmint以外の任意呼出も運べます。

偽造一回で橋の権限すべてを使えるため、特定送信元と形式だけを受け入れ、任意呼出を認めません。

一度計算する

次章の方法を先に使います。

侵害費 = M本の鍵取得費 + Gas + 時間
侵害利益 = 全ロック資産
安全条件：費用 > 利益

ロックは公開情報です。 費用は難しくても検証者の人数、運営者、共通チーム、鍵管理、timelockを調べられます。

ロックだけ二桁増えたなら、まだ順番が来ていない危険状態へ入っています。

何と呼ぶか

実践

- 宛先はロックcontractかEOAか？
- eventに宛先chain、recipient、nonceがあるか？
- 実際のロック残高はいくらか？
- proxyか？upgrade権限とtimelockは？

- 誰が送ったか？relay、validator、本人？
- 関数とproofは？
- mint権限は誰にあるか？
- tokenアドレスは公式の同名tokenと同じか？

不十分：「橋が攻撃されると失う」
十分：「8人のうち5人の鍵が漏れると、Bのwrappedは無担保証書になる」

AI Lab

第一：外部validator、light client、challengeを比較してください。
「___の不正・失敗で資金を失う」と具体的な役割・人数で書き、
遅延、費用、新chain追加難度を添えてください。

第二：伝送、検証、解釈の各障害について、資金損失か停止かを説明してください。

第三：実際のbridge事故を一つ選び、
1. 攻撃取引と操作
2. 失敗した層
3. 別方式でも成立するか
4. 事前の公開情報から見える兆候
を答えてください。

実例

変数を一つ変える

持ち帰る問い

章末チェック