T20 · DEX アーキテクチャ

現実の問題

T19 のプールをフロントエンドへ接続しました。

両準備金から見積もり、「1 ETH は約 3000 USDC」と表示し、確認後に swap へ計算済み出力を渡します。

ローカルでは正常でも、翌日の苦情は二種類でした。

• 取引の失敗。署名後に revert し、Gas は消費します。
• 成功したが表示額と入金額が違う。3000 と表示して、2890 しか届きません。

攻撃もコントラクトのバグも見積もり誤算もないのに、110 はどこへ行きましたか？

見積もりを見てから、実際にチェーンで実行するまで、どれだけ時間があるかに答えがあります。

十数秒から数分です。その間、他ユーザーの通常取引や、見た人の先回りで準備金が変わります。

見積もり、経路選択、実行を一体化し、最も弱い見積もりをオフチェーンへ置いていました。本章で三つを分けます。

思考実験

空港の両替所を考えます。

三工程を別の役が担います。

1. 入口の相場表示：定期更新し、参考値と明示します。
2. 窓口担当：直接か、ドル経由か、二つへ分割するか選びます。
3. 金庫：実際に数えて渡します。

空港では一分以内なので、分かれているとは感じません。

チェーンでは、異なる三時点です。

t0   ブラウザーが準備金を読み、見積もって表示       （オフチェーン、読み取り）
t1   署名してメモリプールへ入る                   （オフチェーン、公開）
t2   ブロック生成者が収録して実行                 （チェーン上、状態は変わり得る）

t0〜t2 は誰でも変えられ、特に t1〜t2 は、取引が公開されています。金額と対象を見て先に約定できます。

窓口で相場表示に従うと言われても、歩く間に表示が変われば、どの価格になりますか？

お金を渡す時に、「これ未満なら交換しない」と言うしかありません。

それが本章の最重要パラメータです。

あなたが決める

表示と違う金額を受け取らせないため、どう変えますか？

結果を観察する

三パラメータは別の問題を防ぎます。

共通するのは、三つとも発信者が署名することです。

ユーザーが制約を付ける唯一の場所です。収録時には、フロントエンド、バックエンド、RPC、Router はユーザーの制御外にあります。

直感に反する点もあります。

許容スリッページは、自分で公開する懸賞額です。

5% を許せば、その範囲の先回り利益を取られても正常に成功し、限界で約定するだけです。

失敗を減らすため大きな既定値を付ける製品もあります。体験の設定でなく、リスク予算です。

モデルを作る

責任、場所、費用の違う三層です。

経路は外で計算し、チェーンは結果だけ検証します。

全プールを列挙して最適を探すのは、Gas が高く、さらに読む準備金自体を操作できます。同取引内で状態を変え、攻撃者に有利な経路を選ばせられます。

経路を署名へ固定すれば、残るのはその経路で実際にいくら受け取ったかという検証です。

Router の骨格です。

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

function swapExactTokensForTokens(
    uint256 amountIn,
    uint256 amountOutMin,     // 発信者の署名に含む下限
    address[] calldata path,  // オフチェーンで計算した経路
    address to,               // 発信者が指定する受取人
    uint256 deadline          // 発信者が指定する有効期限
) external returns (uint256 amountOut) {
    require(block.timestamp <= deadline, "EXPIRED");
    require(path.length >= 2, "BAD_PATH");

    _transferFrom(path[0], msg.sender, _pairFor(path[0], path[1]), amountIn);

    uint256 amount = amountIn;
    for (uint256 i = 0; i + 1 < path.length; i++) {
        amount = _swapOneHop(path[i], path[i + 1], amount, i + 2 == path.length ? to : _pairFor(path[i + 1], path[i + 2]));
    }

    amountOut = amount;
    require(amountOut >= amountOutMin, "INSUFFICIENT_OUTPUT");
}

四点に注意します。

1. deadline は最初に確認します。 期限切れなら何もしません。
2. 途中の受取先は次プールです。 Router に留めず、転送回数も減らします。
3. amountOutMin は最後に確認します。 最終額が達すれば、途中一段の大きなずれがあっても成功すべきです。
4. Router 自体は資金を持ちません。 取引間の残高はゼロが適切です。

二段が一段より良い場合の数学です。

直接：A -> C
  深度 D1 の一プールが全量を担う

二段：A -> B -> C
  深度 D2、D3 で、それぞれのずれが小さい
  代償：手数料が約 0.3% から 0.6%、Gas も増える

有利な条件：
  A/C が浅く、A/B と B/C が深い
  直接の余分なスリッページ > 追加 0.3% と Gas

経路アルゴリズムの問いはこれです。 最短でなく、ずれと手数料を比較します。

何と呼ぶか

実践

A/C  片側 10 万      （浅い）
A/B  片側 500 万     （深い）
B/C  片側 500 万     （深い）

取引額 V、許容幅 s、片側深度 D

1. 許容境界で約定するまで価格を動かす
2. 元本は T19 から、D * (sqrt(1+s) - 1) の程度
3. 粗利は約 V * s
4. 費用は二取引手数料（元本の約 0.6%）、二回 Gas、先回りの入札
5. 純利益 = 粗利 - 費用。正なら実行する

AI Lab

第 1 段階：
準備金と手数料の分かる定積プール群から、
入力、出力資産と入力額に対し、最大受取の経路を求めてください。
重み関数と、最短経路が使えない理由を示してください。

第 2 段階：
最適でない経路を出す三場面の、構造、誤り、代償を示してください。
分割して複数経路を使うなら、アルゴリズムをどう変えますか？
追加 Gas が、どの金額以下で割に合わなくなりますか？

実例

変数を一つ変える

持ち帰る問い

章末チェック