DeFi 協議真實風險量化模型：鏈上數據驗證與實際攻擊事件分析

說到 DeFi 風險，很多人直覺想到「農耕」（yield farming）時那些金光閃閃的 APY 數字，卻忘記了後面藏著多少坑。作為一個在幣圈摸爬滾打好幾年的老兵，我看過太多人只盯著收益率看，結果一夕之間歸零。2023 年的 Euler Finance 事件就是個血淋淋的例子——一個看似保守的借貸協議，一個漏洞直接蒸發了 2 億美元。所以啊，今天就來聊聊怎麼用數學模型把 DeFi 風險給量化出來，別再用直覺玩錢了。

為什麼 DeFi 風險需要量化？

傳統金融有信用評級、CAPM 模型、VaR 等一堆工具幫你評估風險。但 DeFi 呢？很多時候大家還是靠「感覺」——這個協議 TVL 高、這個項目方有知名 VC 背書、這個社群看起來很活躍。問題是，這些指標說不定哪天就讓你資產歸零。

我個人認為，DeFi 風險量化的核心難題在於三個字：去信任。傳統金融機構倒閉了還有存款保險、監管機構來收拾殘局；DeFi 協議要是被駭了，你的資金就像潑出去的水，收不回來。所以我們需要一套不依賴「信任」的客觀量化框架，用鏈上數據說話。

這篇文章要幹的事情很明確：建立一個涵蓋四大風險維度的量化模型，用真實攻擊事件驗證，最後給你可以直接拿來用的 Python 和 Solidity 程式碼。

四大風險維度解析

1. 智能合約風險

先說這個最讓人睡不著覺的風險。智能合約是 DeFi 的核心，同時也是最大的攻擊面。根據 Rekt News 的統計，2024 年全年 DeFi 攻擊事件造成的損失超過 13 億美元，其中超過 60% 涉及智能合約漏洞。

智能合約風險可以拆解成以下幾個子維度：

• 代碼審計覆蓋率：合約是否經過知名審計機構（如 Trail of Bits、OpenZeppelin、Consensys Diligence）審計
• 鎖定資金比例：合約中鎖定的資金佔 TVL 的比例
• 升級頻率：合約是否支持升級，升級治理機制的嚴格程度
• 依賴外部合約數量：合約呼叫了多少外部合約，每個依賴都是潛在攻擊面

量化指標計算

import numpy as np
from dataclasses import dataclass
from typing import List, Dict
from web3 import Web3

@dataclass
class SmartContractRiskMetrics:
    audit_score: float  # 審計評分 0-100
    tvl_locked_ratio: float  # 合約鎖定資金比例
    upgrade_frequency: float  # 月均升級次數
    external_dependency_count: int  # 外部依賴合約數量
    proxy_pattern: bool  # 是否使用代理模式
    pause_function: bool  # 是否有暫停功能
    timelock_delay: int  # 時間鎖延遲（秒）

def calculate_smart_contract_risk(metrics: SmartContractRiskMetrics) -> Dict:
    """
    計算智能合約風險綜合評分
    
    公式: Risk = 100 - (w1*audit + w2*upgrade + w3*dependency + w4*proxy)
    """
    weights = {
        'audit': 0.35,
        'upgrade': 0.20,
        'dependency': 0.25,
        'proxy': 0.20
    }
    
    # 審計分數直接貢獻（需高於門檻才計入）
    audit_component = 35 if metrics.audit_score >= 80 else metrics.audit_score * 0.35
    
    # 升級風險（頻率越高、風險越大）
    upgrade_risk = min(20, metrics.upgrade_frequency * 5)
    
    # 依賴風險（外部呼叫越多風險越高）
    dependency_risk = min(25, metrics.external_dependency_count * 2.5)
    
    # 代理模式風險
    proxy_risk = 20 if metrics.proxy_pattern else 0
    
    total_risk = 100 - (audit_component + upgrade_risk + dependency_risk + proxy_risk)
    
    return {
        'risk_score': max(0, total_risk),
        'risk_level': categorize_risk(total_risk),
        'components': {
            'audit_risk': 100 - audit_component,
            'upgrade_risk': upgrade_risk,
            'dependency_risk': dependency_risk,
            'proxy_risk': proxy_risk
        }
    }

def categorize_risk(score: float) -> str:
    if score < 20:
        return "極低風險"
    elif score < 40:
        return "低風險"
    elif score < 60:
        return "中等風險"
    elif score < 80:
        return "高風險"
    else:
        return "極高風險"

# 實際使用範例
euler_metrics = SmartContractRiskMetrics(
    audit_score=85,
    tvl_locked_ratio=0.95,
    upgrade_frequency=0.5,
    external_dependency_count=12,
    proxy_pattern=True,
    pause_function=True,
    timelock_delay=48*3600
)

risk_result = calculate_smart_contract_risk(euler_metrics)
print(f"Euler Finance 智能合約風險: {risk_result['risk_score']:.2f}")
print(f"風險等級: {risk_result['risk_level']}")

2. 流動性風險

流動性風險經常被新手忽略，覺得「我又不是要馬上跑，關我啥事」。錯了！當市場劇烈波動時，你才發現想要止損卻跑不掉那種絕望。流動性風險的核心問題是：你的訂單簿夠厚嗎？

我個人把流動性風險分成三個層面：

• 市場深度：在當前價格上下 1%、5% 的範圍內能消化多少交易量
• 資金利用率：Pool 中資金被借出或鎖定的比例
• 撤離時間：理論上完全撤離需要多長時間

流動性風險模型

import pandas as pd
from scipy import stats

class LiquidityRiskModel:
    def __init__(self, pool_address: str, web3: Web3):
        self.pool_address = pool_address
        self.w3 = web3
        self.pool_contract = self._load_pool_contract()
    
    def calculate_market_depth(self, price_range_pct: float = 0.01) -> Dict:
        """
        計算市場深度
        
        返回：
        - bid_depth: 買方深度（當前價格以下）
        - ask_depth: 賣方深度（當前價格以上）
        - net_depth: 淨深度
        - depth_ratio: 深度比率（判斷流動性失衡）
        """
        current_price = self.get_current_price()
        
        # 模擬從 Etherscan 獲取的交換事件
        swap_events = self.fetch_swap_events(limit=1000)
        
        bids = []
        asks = []
        
        for event in swap_events:
            price = event['price']
            volume = event['amount_in_usd']
            
            if price < current_price * (1 + price_range_pct):
                bids.append({'price': price, 'volume': volume})
            if price > current_price * (1 - price_range_pct):
                asks.append({'price': price, 'volume': volume})
        
        bid_depth = sum(e['volume'] for e in bids)
        ask_depth = sum(e['volume'] for e in asks)
        
        return {
            'bid_depth': bid_depth,
            'ask_depth': ask_depth,
            'net_depth': bid_depth - ask_depth,
            'depth_ratio': bid_depth / ask_depth if ask_depth > 0 else float('inf'),
            'current_price': current_price,
            'price_range_pct': price_range_pct * 100
        }
    
    def calculate_fund_utilization(self) -> float:
        """
        計算資金利用率
        
        公式: Utilization = Total Borrowed / Total Supply
        """
        total_supply = self.pool_contract.functions.totalSupply().call()
        total_borrow = self.pool_contract.functions.totalBorrow().call()
        
        return total_borrow / total_supply if total_supply > 0 else 0
    
    def estimate_exit_time(self, target_amount: float) -> Dict:
        """
        估算撤離時間（樂觀估計）
        
        假設：
        - 每次交易影響市場價格 0.1%
        - 撤離需要逐步交易避免滑點過大
        """
        current_price = self.get_current_price()
        market_depth = self.calculate_market_depth()['bid_depth']
        
        # 每次交易量
        trade_size = market_depth * 0.001  # 假設每次消化 0.1% 市場深度
        
        if trade_size <= 0:
            return {'exit_time_hours': float('inf'), 'feasible': False}
        
        num_trades = int(target_amount / trade_size) + 1
        avg_slippage_per_trade = 0.001 * (num_trades / 2)  # 遞增滑點
        
        return {
            'exit_time_hours': num_trades * 0.1,  # 假設每筆交易 6 分鐘
            'num_trades': num_trades,
            'avg_slippage': avg_slippage_per_trade * 100,
            'feasible': avg_slippage_per_trade < 0.05  # 5% 滑點以內可視為可行
        }
    
    def get_liquidity_risk_score(self) -> float:
        """
        綜合流動性風險評分（0-100，越高風險越大）
        """
        depth = self.calculate_market_depth()
        utilization = self.calculate_fund_utilization()
        
        # 深度評分（越厚越好）
        depth_score = min(100, depth['bid_depth'] / 1000000) * 100
        
        # 利用率評分（越高風險越大）
        utilization_score = utilization * 100
        
        # 失衡評分（偏離 1 越多風險越大）
        imbalance_score = abs(1 - depth['depth_ratio']) * 50
        
        total_risk = (100 - depth_score) * 0.4 + utilization_score * 0.4 + imbalance_score * 0.2
        
        return min(100, max(0, total_risk))

3. 清算風險

清算風險可以說是借貸協議的命門。2022 年 Terra Luna 崩盤時，我親眼看著一堆人的倉位被瞬間清算，本來只是虧損 30%，結果直接歸零。那種感覺就像坐過山車到最高點突然斷軌往下掉。

清算風險的量化維度：

• 健康因子分佈：借款人健康因子的分佈情況
• 抵押品波動性：抵押品的歷史波動率
• 清算閾值距離：當前價格距離清算價格的空間
• 連環清算機率：假設某大型倉位被清算，對市場的連鎖影響

清算風險量化模型

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

/**
 * @title LiquidationRiskCalculator
 * @notice 清算風險量化模型 Solidity 實現
 * @dev 提供即鏈上結算的清算風險計算
 */
contract LiquidationRiskCalculator {
    
    struct Position {
        uint256 collateralAmount;
        uint256 borrowAmount;
        uint256 collateralPrice;
        uint256 borrowPrice;
        uint256 liquidationThreshold; // 清算閾值（如 0.85 = 85%）
    }
    
    struct LiquidationRiskMetrics {
        uint256 healthFactor;        // 健康因子（放大 100 倍）
        uint256 liquidationDistance; // 距離清算的價格空間（%）
        uint256 cascadeRisk;          // 連環清算機率（0-10000 bps）
        uint256 marketImpact;         // 預計市場影響（%）
    }
    
    /**
     * @notice 計算健康因子
     * @param position 倉位資料
     * @return healthFactor 放大 100 倍的健康因子
     * 
     * 健康因子 = (抵押品價值 * 清算閾值) / 借款價值
     * 
     * 舉例：
     * - 抵押品：10 ETH，價格 $2000，價值 $20,000
     * - 借款：$10,000 USDC
     * - 清算閾值：0.85
     * - 健康因子 = (20000 * 0.85) / 10000 = 1.7
     * 
     * 健康因子 > 1 表示安全，< 1 觸發清算
     */
    function calculateHealthFactor(Position memory position) 
        public 
        pure 
        returns (uint256) 
    {
        if (position.borrowAmount == 0) {
            return type(uint256).max; // 無借款視為無限安全
        }
        
        uint256 collateralValue = position.collateralAmount * position.collateralPrice;
        uint256 adjustedCollateral = (collateralValue * position.liquidationThreshold) / 100;
        
        // 放大 10000 倍避免小數問題
        return (adjustedCollateral * 10000) / position.borrowAmount;
    }
    
    /**
     * @notice 計算距離清算的價格空間
     * @param position 倉位資料
     * @return distanceBps 距離清算的 basis points
     * 
     * 計算方式：
     * 假設抵押品價格下跌到 liquidationPrice 時觸發清算
     * liquidationPrice = borrowAmount / (collateralAmount * liquidationThreshold)
     * 
     * 距離 = (currentPrice - liquidationPrice) / currentPrice
     */
    function calculateLiquidationDistance(Position memory position) 
        public 
        pure 
        returns (uint256) 
    {
        if (position.collateralAmount == 0 || position.borrowAmount == 0) {
            return 10000; // 無借款視為無清算風險
        }
        
        uint256 collateralValue = position.collateralAmount * position.collateralPrice;
        
        // 清算觸發時的抵押品價格
        uint256 liquidationCollateralPrice = 
            (position.borrowAmount * 100) / 
            (position.collateralAmount * position.liquidationThreshold);
        
        if (position.collateralPrice <= liquidationCollateralPrice) {
            return 0; // 已經低於清算價
        }
        
        uint256 priceDrop = position.collateralPrice - liquidationCollateralPrice;
        uint256 distanceBps = (priceDrop * 10000) / position.collateralPrice;
        
        return distanceBps;
    }
    
    /**
     * @notice 估算連環清算風險
     * @param positions 潛在被清算的倉位列表
     * @param targetPosition 目標倉位
     * @param marketDepth 市場深度（可用流動性）
     * 
     * 連環清算的邏輯：
     * 1. 大型倉位被清算 → 大量抵押品拋售
     * 2. 市場價格下跌
     * 3. 導致其他接近清算線的倉位也被清算
     * 4. 形成死亡螺旋
     */
    function estimateCascadeRisk(
        Position[] memory positions,
        Position memory targetPosition,
        uint256 marketDepth
    ) 
        public 
        pure 
        returns (uint256) 
    {
        uint256 totalAtRiskCollateral = 0;
        uint256 totalAtRiskBorrow = 0;
        
        uint256 liquidationDistance = calculateLiquidationDistance(targetPosition);
        
        // 假設市場下跌 10% 觸發目標倉位清算
        uint256 shockSize = 1000; // 10% = 1000 bps
        
        if (liquidationDistance < shockSize) {
            // 目標倉位在震盪下被清算
            uint256 targetLiquidationValue = 
                targetPosition.collateralAmount * targetPosition.collateralPrice;
            
            // 檢查有多少其他倉位會被連帶影響
            for (uint i = 0; i < positions.length; i++) {
                uint256 posDistance = calculateLiquidationDistance(positions[i]);
                
                // 在額外 5% 下跌範圍內的倉位
                if (posDistance >= liquidationDistance && 
                    posDistance < liquidationDistance + 500) {
                    totalAtRiskCollateral += positions[i].collateralAmount * positions[i].collateralPrice;
                    totalAtRiskBorrow += positions[i].borrowAmount;
                }
            }
            
            // 連環風險 = 被影響抵押品價值 / 市場深度
            if (marketDepth > 0) {
                return (totalAtRiskCollateral * 10000) / marketDepth;
            }
        }
        
        return 0;
    }
    
    /**
     * @notice 計算綜合清算風險評分
     */
    function getLiquidationRiskScore(Position memory position) 
        public 
        pure 
        returns (LiquidationRiskMetrics memory) 
    {
        uint256 healthFactor = calculateHealthFactor(position);
        uint256 liquidationDistance = calculateLiquidationDistance(position);
        
        // 健康因子評分（越低風險越高）
        uint256 healthScore;
        if (healthFactor >= 200) {
            healthScore = 0; // 健康因子 > 2 幾乎無風險
        } else if (healthFactor >= 150) {
            healthScore = 20;
        } else if (healthFactor >= 120) {
            healthScore = 50;
        } else if (healthFactor >= 100) {
            healthScore = 80;
        } else {
            healthScore = 100; // 接近或低於 1
        }
        
        // 清算距離評分（越近風險越高）
        uint256 distanceScore;
        if (liquidationDistance >= 2000) {
            distanceScore = 0; // > 20% 空間
        } else if (liquidationDistance >= 1000) {
            distanceScore = 30;
        } else if (liquidationDistance >= 500) {
            distanceScore = 60;
        } else {
            distanceScore = 100; // < 5% 空間
        }
        
        return LiquidationRiskMetrics({
            healthFactor: healthFactor,
            liquidationDistance: liquidationDistance,
            cascadeRisk: 0, // 需要外部數據計算
            marketImpact: 0
        });
    }
}

4. 治理風險

DeFi 的治理機制聽起來很美好——代幣持有者投票決定協議走向。但實際上呢？我看過太多項目方說「我們是去中心化的」，結果創辦人錢包裡躺著 40% 的代幣，投票結果早就內定了。

治理風險的量化維度：

• 代幣集中度：前 10 大持有者佔總供應量的比例
• 投票參與率：歷史提案的平均投票率
• 治理攻擊成本：惡意收購治理權的成本
• 時間鎖機制：參數變更是否需要時間鎖延遲

實際攻擊事件分析

Euler Finance 攻擊事件（2023年3月）

這事件我到現在想起來都還心有餘悸。攻擊者利用了一個所謂「Donate to LPs」函數的漏洞，繞過了健康因子檢查，直接把協議搞成資不抵債。最終損失 1.97 億美元，佔當時 TVL 的 90% 以上。

用我們的模型回測：

def backtest_euler_attack():
    """
    使用攻擊前的數據回測我們的風險模型
    """
    print("=" * 60)
    print("Euler Finance 攻擊事件回測")
    print("=" * 60)
    
    # 攻擊前的智能合約指標
    euler_metrics = SmartContractRiskMetrics(
        audit_score=75,  # 有審計但仍有漏洞
        tvl_locked_ratio=0.92,
        upgrade_frequency=0.3,
        external_dependency_count=15,  # 依賴複雜
        proxy_pattern=True,
        pause_function=True,
        timelock_delay=24*3600  # 24小時延遲
    )
    
    sc_risk = calculate_smart_contract_risk(euler_metrics)
    print(f"\n智能合約風險評分: {sc_risk['risk_score']:.2f}/100")
    print(f"風險等級: {sc_risk['risk_level']}")
    
    # 攻擊前的流動性指標
    # TVL: ~$250M, 實際可用流動性估算: ~$50M
    # 大規模攻擊需要瞬間消化大量流動性
    print(f"\n流動性分析:")
    print(f"  TVL: $250M")
    print(f"  可用流動性估算: $50M")
    print(f"  攻擊規模: $197M")
    print(f"  結論: 流動性不足以支撐大規模清算")
    
    # 為什麼傳統風險模型失效？
    print(f"\n傳統風險模型失效原因:")
    print(f"  1. 審計覆蓋了大部分代碼，但忽略特定邏輯漏洞")
    print(f"  2. 健康因子檢查存在於合約介面，但實際邏輯有繞過路徑")
    print(f"  3. 依賴外部預言機定價，攻擊操縱了瞬時價格")
    print(f"  4. 時間鎖延遲不足以阻止組合攻擊")
    
    return {
        'smart_contract_risk': sc_risk['risk_score'],
        'liquidity_coverage': 50 / 197,  # 流動性覆蓋率
        'attack_scale_usd': 197_000_000
    }

result = backtest_euler_attack()

Compound Finance 清算漏洞（2021年10月）

這次事件比較低調，但教訓同樣深刻。當時代碼升級時出現了一個 bug，導致價值 8000 萬美元的 COMP 代幣被錯誤分發。雖然最終追回了大部分資金，但這個案例暴露了升級機制的風險。

我個人的觀察是：DeFi 協議的代碼質量兩年內很難達到傳統金融級別。不是開發者不給力，而是這個領域的攻擊面實在太新穎、太複雜。

CREAM Finance 攻擊事件（2021年8月）

攻擊者利用 Flash Loan 進行了 5 億美元的攻擊，刷新了當時的紀錄。這次攻擊的特點是：

1. 攻擊成本極低（只需要操縱市場）
2. 利潤極高
3. 幾乎無法防禦

用我們的模型，這類攻擊屬於「市場操縱」類風險，很難在鏈上完全防禦，但可以通過以下方式降低影響：

• 限制單一地址的借款上限
• 增加清算冷卻期
• 引入預言機防操縱機制

整合風險量化框架

把所有維度整合成一個綜合評分：

class DeFiProtocolRiskFramework:
    def __init__(
        self,
        smart_contract_metrics: SmartContractRiskMetrics,
        pool_address: str = None,
        positions: List[Position] = None,
        governance_data: Dict = None
    ):
        self.sc_metrics = smart_contract_metrics
        self.pool_address = pool_address
        self.positions = positions
        self.governance_data = governance_data
        
    def calculate_comprehensive_risk(self) -> Dict:
        """
        計算綜合風險評分
        
        權重分配：
        - 智能合約風險: 40%
        - 流動性風險: 25%
        - 清算風險: 20%
        - 治理風險: 15%
        """
        sc_risk = calculate_smart_contract_risk(self.sc_metrics)
        
        liquidity_risk = 0
        if self.pool_address:
            liquidity_model = LiquidityRiskModel(self.pool_address, Web3())
            liquidity_risk = liquidity_model.get_liquidity_risk_score()
        
        liquidation_risk = 0
        if self.positions:
            avg_health = sum(
                calculate_health_factor(p) for p in self.positions
            ) / len(self.positions)
            # 健康因子越低，清算風險越高
            liquidation_risk = max(0, 100 - avg_health * 50)
        
        governance_risk = 0
        if self.governance_data:
            # 代幣集中度風險
            concentration = self.governance_data.get('top10_concentration', 0)
            concentration_risk = min(50, concentration * 0.5)
            
            # 投票參與率風險（越低越容易被操控）
            participation = self.governance_data.get('avg_participation', 0.05)
            participation_risk = max(0, 50 - participation * 500)
            
            governance_risk = concentration_risk + participation_risk
        
        # 綜合評分
        total_risk = (
            sc_risk['risk_score'] * 0.40 +
            liquidity_risk * 0.25 +
            liquidation_risk * 0.20 +
            governance_risk * 0.15
        )
        
        return {
            'comprehensive_risk_score': total_risk,
            'risk_level': categorize_risk(total_risk),
            'breakdown': {
                'smart_contract': sc_risk['risk_score'],
                'liquidity': liquidity_risk,
                'liquidation': liquidation_risk,
                'governance': governance_risk
            },
            'recommendation': self._get_recommendation(total_risk)
        }
    
    def _get_recommendation(self, risk_score: float) -> str:
        if risk_score < 25:
            return "積極參與：風險可控，預期收益合理"
        elif risk_score < 45:
            return "適度參與：建議控制倉位在總資產 20% 以內"
        elif risk_score < 65:
            return "謹慎參與：僅投入閒置資金，密切監控倉位"
        else:
            return "建議觀望：風險過高，等待協議成熟或審計更新"

實用建議

說了這麼多理論，來點乾貨。我自己每天在用的風險檢查清單：

進倉前必查

1. 審計報告看三遍：不是看結論「通過」，而是逐條看修補的漏洞
2. 代理合約的 Owner：誰有權限升級？時間鎖多久？
3. TVL 與流動性比：TVL 虛高但流動性差的要小心
4. 借款利用率：超過 80% 的資金池要警覺
5. 社群情緒：Twitter 和 Discord 有沒有異常抱怨

持倉期間監控

1. 健康因子警報：設在 1.5 以下就提醒
2. 巨額轉帳監控：盯著大戶錢包
3. 治理提案追蹤：有沒有異常大的提案
4. 合約事件日誌：有沒有新的可疑合約呼叫

風險管理策略

1. 分散協議：雞蛋不要放一個籃子
2. 設置止損：別相信「HODL」那套鬼話
3. 保留現金：暴跌時有子彈才能抄底
4. 定期審視：至少每週檢查一次倉位健康

結語

DeFi 風險量化這件事，說到底就是在跟「不確定性」打交道。我們能做的，不是消滅風險，而是更精確地測量它、量化它、然後在風險和收益之間找到自己的舒適區。

這套框架當然不是完美的——攻擊者的創意永遠領先於防禦者。但至少，下次你看到一個 APY 1000% 的池子時，心裡能有個數：這麼高的收益，背後到底是什麼支撐的？

記住，在 DeFi 這個戰場上，活下來比賺得快更重要。願各位讀者都能在下一個黑天鵝事件中安然度過。

數據截止日期：2026-03-29

參考來源：

• Etherscan（攻擊事件鏈上數據驗證）
• Dune Analytics（TVL 與清算歷史數據）
• DeFi Llama（協議 TVL 追蹤）
• Rekt News（攻擊事件資料庫）
• 各大協議官方文檔

免責聲明：本網站內容僅供教育與資訊目的，不構成任何投資建議或推薦。在進行任何加密貨幣相關操作前，請自行研究並諮詢專業人士意見。所有投資均有風險，請謹慎評估您的風險承受能力。