T4 · DeFi Engineer
金融の仕組みを実装する段階から、どんな相場で誰に損失が生じるか説明できる段階へ。
金融エンジニアリングの分野向けです。
このページの T4 は Track です。講座の章は「第 T22 章」のようにリンク付きで区別します。講座の T4 は RPC を扱います。
この Track に向いている人
AMM を実装したが、数値の正しさしか検証していない。 スリッページ、手数料、流動性の追加と撤去は通っても、一ブロックで価格が 40 パーセント下落する場合をテストしたことがありません。
プロトコル名は知っていても、リスク構造を区別できない。 貸付の清算、無期限先物の資金調達率、AMM の一時的損失について、誰が負担し、誰が払うかを明確に答えられません。
式は書けても、パラメーターを決められない。 担保率 75 か 80 パーセント、清算報酬 5 か 8 パーセント、金利の折点 80 か 90 パーセントを、既存のプロトコルから写しています。
通常の相場でしかテストしていない。 価格は安定し、流動性は十分、清算者は即座に来るという前提が、事故時にはすべて崩れます。
境界は、どんな条件で不良債権が生じ、誰が負担するかの説明書と、それを実装するコードを提供することです。
前提
仕組みの理由は Part A、実装方法は Part B にあり、両方が必要です。 第 T19 章が第 14・T12 章に依存するのも、そのためです。
- 第 14–15 章
- 第 16–18 章
- 第 T9 章
- 第 T12 章
- 第 T19 章
- 第 T20 章
- 第 T21 章
- 第 T22 章
- 第 T23 章
| 先に読む章 | グラフ上の理由 |
|---|---|
| 第 14 章 · DEX はなぜ中央取引所なしで動くか | 第 T19 章の直接の前提。なければ書くのは市場ではなく数学になる |
| 第 15 章 · 流動性とは何か | 実際に回収できる資金。すべてのリスク議論の土台 |
| 第 16 章と第 18 章 | 第 T22・T23 章の直接の前提。信用を清算へ置き換え、レバレッジがフィードバックを生む |
| 第 T9 章 · ERC Standards | 第 T19 章の直接の前提。どのトークンも標準どおりとは限らない |
| 第 T12 章 · Testing & Deployment | 同じく第 T19 章の前提。金融プロトコルはメインネットを Fork してテストする必要があり、さもなければ存在しない市場を測る |
| 第 T19 章と第 T20 章 | 定積のコード化、見積り・経路・実行の分離 |
| 第 T21 章 · Oracle | 第 T22 章の直接の前提。価格があって初めて清算を論じられる |
| 第 T22 章と第 T23 章 | 清算エンジンとリスクエンジン。成果物の基盤 |
第 T24 章 · MEVも着手前に強く勧めます。清算報酬と価格更新は、取引順序の市場で再評価されます。
学ぶ内容
- AMM
- CLMM
- Order Book
- Lending
- Perp
- Oracle
- Risk Engine
七テーマを三群と、まとめの一群へ分けます。
1．取引場所：AMM、CLMM、Order Book — 価格形成
三つは技術の世代ではなく、異なる制約での解です。資産ペアとチェーンの費用構造に対し、選ぶ方式と代償を説明できる判断力を作ります。
| 構造 | 価格の源泉 | 主なリスク | 適する対象 |
|---|---|---|---|
| 定積 | 準備資産の比率から受動的に決まる | 価格変化で保有構成が変わる | 長尾の資産、能動的なマーケットメーカーがいない場合 |
| 集中流動性 | 同様だが、範囲内だけ提供する | 同様のリスクに加え、範囲外で手数料収入が止まる | 相関の高いペア、資金効率を重視する場合 |
| 注文板 | 注文者が能動的に決める | 古い見積りが約定される | 照合費用が低く、専門の担い手がいる場合 |
集中流動性では、範囲と tick、範囲を越える状態遷移、範囲ごとの手数料記帳まで実装します。難所は数学より、浮動小数の直感を精度を失わない固定小数整数演算へ変えることです。
2．信用とレバレッジ：Lending、Perp — リスクの負担
貸付の安全の境界は、金利モデルの美しさより清算速度です。これを実装できる部分へ分けます。
- 健全性の定義と更新時点。操作ごとに計算するか、外部が起動するか
- 清算報酬。低ければ誰も来ず、高ければ損失が増え、Gas と厚みで閾値が変わる
- 不良債権の負担。保険基金、LP の比例負担、損失の社会化のどれか
- 無期限先物の証拠金方式、資金調達率、マーク価格と指数価格、自動デレバレッジの条件
最後は連鎖清算です。清算が価格を下げ、次の清算を起こす回路をテストで再現し、保険基金の消費を測ります。
3．価格の源泉：Oracle — 数字を信じる根拠
オラクルはよくある単一障害点です。更新頻度、乖離幅、ハートビートの期限、古いデータでの縮退を確認可能な条件へ分解します。
操作にいくら必要で、プロトコルからいくら取れるかを自分で計算します。並べると価格方式の安全性が見えます。
4．まとめ：Risk Engine — 拒否できるシステム
モジュール名ではなく、実行前に許容できない状態になるかを判断する責務です。上限、証拠金、集中度、価格の有効性、合法な取引をいつ拒否すべきかを扱います。
この層が、動く DeFi demo と卒業成果物の違いです。
卒業成果物
リスクエンジンを備えた取引または貸付プロトコル。
卒業プロジェクトは全体のシステム、この Track は一層ですが、極端な相場での動作を説明できる必要があります。リスクエンジンがなければ、提供を完了したとは扱いません。
他者が動かせるか。 clone 後、一コマンドで依存、一コマンドで Fork を含む全テストを実行します。チェーン、高さ、そこに必要な実際の流動性があるなどの選定理由を README に書きます。
ローカルで崩落時の挙動を見られるスクリプトも付けます。
拒否でき、記録があるか。 古い価格、乖離超過、一件の上限超過、集中度超過、健全性不足の最低五種類を拒否します。
各状態を作り、拒否と区別可能な理由をテストします。すべて通すリスクエンジンは、ないのと同じです。
極端な相場を全過程で訓練したか。 一ブロックで急落する状況を作り、清算対象数、間に合った数、不良債権額を記録します。
誰がどの順に負担するかを答えます。答えられなければ設計が未完です。
オラクルの攻撃費用を計算したか。 方式、必要資金、維持ブロック数、成功時に取れる額を示します。
割に合うなら方式を変えるか、防がない範囲と負担者を脅威モデルへ書きます。明確な放棄は専門的ですが、存在を無視するのは違います。
パラメーターに根拠があるか。 担保率、報酬、金利の折点、資金調達率係数に、変動、厚み、清算遅延の仮定を示します。
他のプロトコルを参考にしても、その仮定が自分にも成立する理由を書きます。
メインネットの前にテストネットで一巡し、少額と上限を設定します。 テストネットと完全なパラメーターの論証だけでも評価は成立します。
達成したかを判断するには
攻撃者は一取引で、大量購入して価格を上げ、その価格で担保を評価して実価値以上を借り、プールのポジションを解消します。
同じブロック、同じ取引なので価格が戻る機会がなく、瞬間価格の検査は通ります。フラッシュローンなら元本はほぼ不要で、手数料だけを負担します。
時間加重、独立した複数源、同ブロック内で完了できない制約が防御方向です。ただし時間加重は価格を遅らせ、急変時の清算も遅らせます。
一つ目は、Gas と取引順序の対価を含む清算者の費用です。報酬が上回らなければ来ません。
二つ目は厚みです。担保売却のスリッページが大きいほど、余裕が必要です。
三つ目は変動速度です。清算可能から実行までの遅延中も価格が動き、速いほど安全幅が必要です。
高すぎると利用者の損失が増え、清算条件を作る誘因も生みます。答えは写した一数字より範囲です。Gas と市場で変化し、調整可能性とタイムロックが必要だと述べれば加点です。
先物が現物より高いとロングがショートへ払い、ロングを高くして価格を戻す経済圧力です。強制ではありません。
一方向の相場では期待利益が大きく、高い費用でも買います。流動性の枯渇では現物の借入や厚みが不足して裁定ができず、支払いは移転だけとなり、収束させません。
安全機構と扱ってはいけません。極端な状況を防ぐのは証拠金、清算の閾値、自動デレバレッジであり、資金調達率は平常時を担います。
固定小数演算の精度と丸め方向です。
tick と価格は指数関係で、流動性、手数料、範囲遷移は整数演算です。最小単位の逆向きの丸めでも、数百万回で実際の資金になります。
第 T28 章の通り、丸め方向を常にプロトコルに有利にします。 保有資産が各ポジションの権利の合計以上、などの不変条件を Fuzzing で検証し、個々の除算の目視だけに頼りません。
正解は一つではありません。三つを確認します。
- 集中リスクとして、一者が通常清算できない大きさでも処理は成立しますか。
- 全額を突然引き出したとき、依存する機能はどうなりますか。
- リスクエンジンは一件の額だけでなく、一参加者の比率も制限しますか。
制限は一件でも、リスクは累積から生まれる点を見落としがちです。
よくある誤解
数値テストが通れば仕組みは正しい
指定入力で式が正しいことを測るだけです。事故は状態の組合せ、特定の価格、厚み、清算者の不在から生まれます。
性質を不変条件にして状態を持つ Fuzzing へ渡し、極端な相場のシナリオも加えます。数値テストは最低条件です。
成熟したプロトコルの値なら安全
値は変動、Gas、清算者、厚みの仮定を表すため、環境が変われば成立しません。
仮定を書き、成立時と不成立時を検証します。調整でき、タイムロックがあることは、一度で正しく選ぶことより重要です。
オラクルを使わないのでリスクなし
自分のプール比率や外部見積りを含め、価格を参照すればオラクルがあります。差は操作費用です。
源泉と操作費用を必答にし、第 T21 章の計算を自分で行います。
清算コードが正しければ清算される
外部参加者が能動的に実行する必要があります。正しさは来た場合の成功だけを保証します。急変時には Gas、順序の競争、清算者の資金拘束が同時に起きます。
清算者を、報酬を設計する相手と扱います。N ブロックの遅延を明示的に再現し、保険基金が耐えるかを測ります。
次に進むには
- 自分のプロトコルとともに、第 T21 章、第 T22 章、第 T24 章を読み直します。
- パラメーター確定後、第 T29 章 · Protocol Securityの攻撃費用表を使います。
- Track T5 · Security Engineerで検証、Track T1 · EVM Engineerで実装、Track T3 · Onchain Data Engineerで実データを補います。
- 非技術側は Track N1 · Crypto Research & Investmentです。清算を実装できる人は、設計された数字と市場が生んだ数字を区別できます。
- 全体のプロダクトへつなぐなら卒業プロジェクトへ進みます。