加密貨幣交易所 × BitGo 託管架構完整說明
文件目的：說明交易所使用第三方託管服務（如 BitGo）時的完整運作模式、資金流設計、風控機制與工程實務架構。
先看白話版（3 分鐘懂）
角色比喻
想像你去銀行存錢、領錢：
| 現實世界 | 加密貨幣世界 | 做什麼 |
|---|---|---|
| 銀行櫃臺 | 交易所（Exchange） | 記帳、審核、擋詐騙 |
| 金庫 + 保全 | BitGo（託管方） | 保管鑰匙、開金庫門、把錢送出去 |
| 央行公開帳冊 | 區塊鏈（Blockchain） | 記錄所有交易，公開透明、不可竄改 |
| 你的存摺 | 內部帳本（Ledger） | 你在交易所看到的餘額 |
為什麼要分開？ 就像銀行櫃員不該自己拿金庫鑰匙一樣——權責分離才安全。
入金白話（存錢）
你（用戶）想把 1 BTC 存進交易所：
1. 交易所先跟 BitGo「申請一個專屬收款地址」給你
→ 就像銀行給你一個帳號
2. 你從自己的錢包把 1 BTC 轉到這個地址
→ 就像你用 ATM 轉帳
3. 區塊鏈開始確認這筆交易（等 3~6 次確認）
→ 就像銀行等跨行清算完成
4. BitGo 偵測到入帳，用 webhook 通知交易所
→ 就像對方銀行通知你的銀行「錢到了」
5. 交易所在你的內部帳本 +1 BTC
→ 你的 App 上看到餘額增加了
⚠️ 但交易所不能只看通知就加錢！
每天還要拿「帳本餘額」vs「鏈上實際餘額」做交叉比對（對帳）
→ 就像銀行每天軋帳
提幣白話（領錢）
你想從交易所提 0.5 BTC 到自己的錢包：
1. 你在 App 上按「提幣」
↓
2. 交易所做一連串檢查：
├─ 你是誰？（KYC 身份驗證）
├─ 這個地址安不安全？（AML 反洗錢）
├─ 你帳上有那麼多嗎？（餘額驗證）
├─ 今天提太多了嗎？（限額判斷）
└─ 看起來正常嗎？（風控模型）
↓
3. 全部通過 → 丟進「提款排隊區」
↓
4. 交易所呼叫 BitGo API：「請幫我轉 0.5 BTC 到這個地址」
↓
5. BitGo 內部再做一次審核（Policy Engine）：
├─ 小額 → 自動放行
├─ 大額 → 需要主管審批
└─ 超大額 → 多人簽名（Multi-sig / MPC）
↓
6. 簽名完成 → 廣播到區塊鏈 → 完成
重點：
「能不能提」→ 交易所說了算
「怎麼安全地把錢轉出去」→ BitGo 說了算
錢包分層白話（金庫管理）
想像交易所的錢分三個地方放：
┌─────────────────────────────────────────────────┐
│ │
│ 🔥 熱錢包（Hot Wallet）── 收銀臺的零錢箱 │
│ 放 3~5% 的錢 │
│ 特點：隨時可用、但放少量、被搶損失小 │
│ │
│ 🌡️ 溫錢包（Warm Wallet）── 辦公室保險箱 │
│ 放 10~15% 的錢 │
│ 特點：需要授權才能開、用來補零錢箱 │
│ │
│ 🧊 冷錢包（Cold Custody）── 銀行金庫 │
│ 放 80%+ 的錢 │
│ 特點：離線保管、多人簽名才能動、最安全 │
│ │
└─────────────────────────────────────────────────┘
錢的流向：冷 → 溫 → 熱 → 用戶提幣
（平時大部分錢鎖在金庫，只在需要時才一層一層搬出來）
一句話總結
這套架構的本質是用「權責分離 + 多層防線」換到安全、流動性與合規的平衡。
一、整體系統架構
全景圖
┌────────────────────────────────────────────────────────────────────────┐
│ 用戶層（User Layer） │
│ │
│ 📱 Mobile App 💻 Web App 🤖 API Client │
│ │ │ │ │
│ └──────────────────────┴────────────────────┘ │
│ │ │
│ HTTPS / WSS │
│ │ │
├──────────────────────────────┼─────────────────────────────────────────┤
│ 交易所後端（Exchange Backend） │
│ │ │
│ ┌───────────────┐ ┌───────────────┐ ┌───────────────┐ │
│ │ API Gateway │ │ Auth Service │ │ Rate Limiter │ │
│ └───────┬───────┘ └───────────────┘ └───────────────┘ │
│ │ │
│ ┌───────┴─────────────────────────────────────────────────┐ │
│ │ 核心業務服務 │ │
│ │ │ │
│ │ ┌──────────────┐ ┌─────────────────┐ ┌──────────────┐ │ │
│ │ │ User Account │ │ Risk Engine │ │ Withdraw │ │ │
│ │ │ Ledger │ │ 風控引擎 │ │ Queue │ │ │
│ │ │ 用戶帳本 │ │ │ │ 提款佇列 │ │ │
│ │ └──────────────┘ └─────────────────┘ └──────────────┘ │ │
│ │ │ │
│ │ ┌──────────────┐ ┌─────────────────┐ ┌──────────────┐ │ │
│ │ │Reconciliation│ │ Liquidity │ │ Deposit │ │ │
│ │ │ Service │ │ Monitor │ │ Processor │ │ │
│ │ │ 對帳服務 │ │ 流動性監控 │ │ 入金處理器 │ │ │
│ │ └──────────────┘ └─────────────────┘ └──────────────┘ │ │
│ └──────────────────────────┬──────────────────────────────┘ │
│ │ │
├──────────────────────────────┼─────────────────────────────────────────┤
│ │ REST API / Webhook │
│ │ │
│ 託管層（Custodian Layer - BitGo） │
│ │ │
│ ┌───────────────────────────┴────────────────────────────┐ │
│ │ │ │
│ │ ┌────────────┐ ┌─────────────┐ ┌──────────────┐ │ │
│ │ │ Hot Wallet │ │ Warm Wallet │ │ Cold Custody │ │ │
│ │ │ 熱錢包 │ │ 溫錢包 │ │ 冷錢包 │ │ │
│ │ │ 3~5% │ │ 10~15% │ │ 80%+ │ │ │
│ │ └────────────┘ └─────────────┘ └──────────────┘ │ │
│ │ │ │
│ │ ┌────────────────────────────────────────────────┐ │ │
│ │ │ Policy Engine（策略引擎） │ │ │
│ │ │ ├─ Approval Rules（審批規則） │ │ │
│ │ │ ├─ Multi-sig（多重簽名） │ │ │
│ │ │ ├─ MPC（多方計算） │ │ │
│ │ │ └─ Whitelist（地址白名單） │ │ │
│ │ └────────────────────────────────────────────────┘ │ │
│ └──────────────────────────┬─────────────────────────────┘ │
│ │ │
├──────────────────────────────┼─────────────────────────────────────────┤
│ │ 簽名 & 廣播 │
│ │ │
│ 區塊鏈層（Blockchain Layer） │
│ │ │
│ ┌──────────────────────────────────────────────────────┐ │
│ │ BTC Network │ ETH Network │ 其他鏈 ... │ │
│ │ ┌─────┐ │ ┌─────┐ │ ┌─────┐ │ │
│ │ │Node │ │ │Node │ │ │Node │ │ │
│ │ │ ⛓️ │ │ │ ⛓️ │ │ │ ⛓️ │ │ │
│ │ └─────┘ │ └─────┘ │ └─────┘ │ │
│ └──────────────────────────────────────────────────────┘ │
│ │
└────────────────────────────────────────────────────────────────────────┘
核心責任分工
┌─────────────────────────────┐ ┌─────────────────────────────┐
│ 交易所負責什麼？ │ │ 託管方負責什麼？ │
│ │ │ │
│ ✅ 用戶帳本管理 │ │ ✅ 私鑰安全保管 │
│ ✅ KYC / AML 合規 │ │ ✅ 交易簽名（sign） │
│ ✅ 風控模型判斷 │ │ ✅ 交易廣播（broadcast） │
│ ✅ 提款審核與排隊 │ │ ✅ 多重簽名 / MPC │
│ ✅ 流動性管理 │ │ ✅ 策略引擎（審批規則） │
│ ✅ 對帳服務 │ │ ✅ 地址生成與管理 │
│ ✅ 手續費估算 │ │ ✅ 鏈上交易監控 │
│ │ │ │
│ 一句話：決定「能不能做」 │ │ 一句話：決定「怎麼安全做」 │
└─────────────────────────────┘ └─────────────────────────────┘
二、入金流程（Deposit Flow）
完整入金時序圖
用戶 交易所後端 BitGo（託管方） 區塊鏈
│ │ │ │
│ 1.請求入金地址 │ │ │
│─────────────────>│ │ │
│ │ 2.createAddress() │ │
│ │───────────────────>│ │
│ │ 3.回傳專屬地址 │ │
│ │<───────────────────│ │
│ 4.顯示地址 │ │ │
│<─────────────────│ │ │
│ │ │ │
│ 5.用戶轉帳到此地址 │ │
│─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ >│
│ │ │ 6.偵測到入帳 │
│ │ │<──────────────────│
│ │ │ 7.等待 N 次確認 │
│ │ │<──────────────────│
│ │ 8.webhook 通知 │ │
│ │<───────────────────│ │
│ │ │ │
│ │ 9.驗證 webhook │ │
│ │ （HMAC 簽名驗證） │ │
│ │ │ │
│ │ 10.更新帳本 +餘額 │ │
│ │──(內部)────> │ │
│ 11.餘額更新 │ │ │
│<─────────────────│ │ │
│ │ │ │
│ │ 12.定期對帳（帳本 vs 鏈上） │
│ │─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─>│
1. 建立地址
- 交易所後端呼叫 API 建立地址
- 每位用戶一個地址，或「地址 + Memo」（依鏈種）
Backend → Custodian API → createAddress()
白話：就像銀行開戶時給你一個帳號。BTC/ETH 每人一個獨立地址；XRP/EOS 等鏈用「共用地址 + Memo 備註」來區分用戶（類似銀行帳號 + 附言）。
2. 用戶轉帳
User → Blockchain → Custodian Wallet
- 託管方監聽鏈上交易
- 等待確認數（confirmations）
- 透過 webhook 通知交易所
白話：用戶把幣從自己的錢包轉過來。BitGo 會一直「盯著」區塊鏈看有沒有新的入帳。BTC 通常等 3~6 個區塊確認（約 30~60 分鐘），ETH 等 12~32 個區塊確認（約 3~7 分鐘）。確認夠多後，BitGo 才通知交易所。
為什麼要等確認？ 防止「雙花攻擊」——攻擊者先轉帳給你，等你加了餘額後又把交易撤回。確認次數越多，被撤回的機率越低。
3. 帳本入帳
Webhook → Backend → Credit User Ledger
重要原則：
- Webhook 不可作為唯一依據
- 必須定期做鏈上對帳（on-chain reconciliation）
白話：Webhook 就像快遞通知「你的包裹到了」，但你不能光憑通知就確認——萬一通知是假的呢？所以交易所必須自己去鏈上查一遍，就像你去門口看看包裹是不是真的在那裡。
對帳的具體做法：
每天凌晨 3:00 自動執行：
1. 拉出所有用戶帳本餘額加總 → SUM_ledger
2. 查詢 BitGo 報告的錢包餘額 → SUM_custodian
3. 直接查鏈上地址餘額 → SUM_onchain
SUM_ledger == SUM_custodian == SUM_onchain → ✅ 正常
任何不等 → 🚨 立即告警，人工介入
三、提幣流程（Withdraw Flow）
完整提幣時序圖
用戶 交易所後端 BitGo（託管方） 區塊鏈
│ │ │ │
│ 1.申請提幣 │ │ │
│───────────────>│ │ │
│ │ │ │
│ │ 2.交易所內部審核 │ │
│ │ ┌──────────────┐ │ │
│ │ │ KYC/AML 檢查 │ │ │
│ │ │ 風控模型評估 │ │ │
│ │ │ 餘額是否足夠 │ │ │
│ │ │ 今日限額檢查 │ │ │
│ │ │ 冷卻期檢查 │ │ │
│ │ └──────┬───────┘ │ │
│ │ │ │ │
│ │ 通過？│ │ │
│ │ ├─ 否 → 拒絕，通知用戶 │
│ │ └─ 是 ↓ │ │
│ │ │ │
│ │ 3.進入提款佇列 │ │
│ │ ┌──────────────┐ │ │
│ │ │ Withdraw │ │ │
│ │ │ Queue │ │ │
│ │ │ (可做併單) │ │ │
│ │ └──────┬───────┘ │ │
│ │ │ │ │
│ │ 4.呼叫 send() │ │
│ │───────────────────>│ │
│ │ │ │
│ │ 5.BitGo Policy Engine │
│ │ ┌─────────────────┐ │
│ │ │ < 0.1 BTC │ │
│ │ │ → 自動放行 │ │
│ │ │ │ │
│ │ │ 0.1~10 BTC │ │
│ │ │ → 主管審批 │ │
│ │ │ │ │
│ │ │ > 10 BTC │ │
│ │ │ → Multi-sig │ │
│ │ │ 多人簽名 │ │
│ │ └───────┬─────────┘ │
│ │ │ │
│ │ 6.簽名交易 │
│ │ │ │
│ │ 7.廣播到區塊鏈 │
│ │ │──────────────────>│
│ │ │ │
│ │ 8.回傳 txHash │ │
│ │<───────────────────│ │
│ 9.通知進度 │ │ │
│<───────────────│ │ │
│ │ │ 10.鏈上確認 │
│ │ 11.webhook 確認 │<──────────────────│
│ │<───────────────────│ │
│ 12.提幣完成 │ │ │
│<───────────────│ │ │
各階段白話說明
| 階段 | 誰負責 | 做什麼 | 為什麼 |
|---|---|---|---|
| KYC/AML | 交易所 | 確認身份、檢查洗錢風險 | 法規要求，防止犯罪 |
| 風控模型 | 交易所 | 異常行為偵測（如：突然大量提款） | 防止帳號被盜 |
| 餘額驗證 | 交易所 | 帳本上夠不夠 | 不能超支 |
| 提款佇列 | 交易所 | 排隊等候處理，可合併多筆 | 節省鏈上手續費 |
| Policy Engine | BitGo | 根據金額大小決定審批流程 | 大額交易需要更高安全級別 |
| 簽名 & 廣播 | BitGo | 用私鑰簽名、送上鏈 | 沒有私鑰簽名，交易無效 |
四、錢包分層設計（資金配置模型）
分層架構圖
用戶提幣請求
│
▼
┌─────────────────────────────────────────────────────────┐
│ 🔥 熱錢包（Hot Wallet） │
│ ┌────────────────────────────────────────────────┐ │
│ │ 比例：3~5% 總資產 │ │
│ │ 連線：全天候在線 │ │
│ │ 簽名：自動化（API 可直接觸發） │ │
│ │ 用途：處理即時小額提款 │ │
│ │ 風險：最高（私鑰在線上伺服器） │ │
│ │ │ │
│ │ 白話：超商收銀臺的零錢 │ │
│ └────────────────────────────────────────────────┘ │
│ ▲ 當餘額低於門檻時，自動觸發補倉 │
├─────────┼───────────────────────────────────────────────┤
│ │ │
│ 🌡️ 溫錢包（Warm Wallet） │
│ ┌─────────────────────────────────────────────────┐ │
│ │ 比例：10~15% 總資產 │ │
│ │ 連線：半離線（需授權才啟動） │ │
│ │ 簽名：需 1~2 位主管審批 │ │
│ │ 用途：定期補充熱錢包、處理中等金額提款 │ │
│ │ 風險：中等 │ │
│ │ │ │
│ │ 白話：辦公室保險箱，經理有鑰匙 │ │
│ └─────────────────────────────────────────────────┘ │
│ ▲ 需要人工審批或排程補倉 │
├─────────┼───────────────────────────────────────────────┤
│ │ │
│ 🧊 冷錢包（Cold Custody） │
│ ┌────────────────────────────────────────────────┐ │
│ │ 比例：80%+ 總資產 │ │
│ │ 連線：完全離線（Air-gapped） │ │
│ │ 簽名：Multi-sig（2-of-3 或 3-of-5） │ │
│ │ 用途：長期資產存管 │ │
│ │ 風險：最低（私鑰從未接觸網路） │ │
│ │ │ │
│ │ 白話：銀行地下金庫，多把鑰匙同時到才能開 │ │
│ └────────────────────────────────────────────────┘ │
└─────────────────────────────────────────────────────────┘
資金流向：冷 ──→ 溫 ──→ 熱 ──→ 用戶
（永遠是單向補充，就像水從水庫流向水龍頭）
設計目標
- 熱錢包保持低暴露：就算被駭，損失只有 3~5%
- 冷錢包保持高安全：離線 + 多簽，駭客摸不到
- 兼顧提款流動性：用戶不會因為「錢在冷錢包」就提不出來
五、熱錢包補倉機制
補倉流程圖
┌───────────────────────────────────────────────────────┐
│ 流動性監控服務（每 5 分鐘檢查） │
│ │
│ hot_balance < low_threshold? │
│ │ │
│ 是 │ 否 │
│ ▼ └→ 不動作 │
│ ┌───────────────────────┐ │
│ │ 計算補充金額 │ │
│ │ amount = target │ │
│ │ - hot_balance │ │
│ └──────────┬────────────┘ │
│ │ │
│ ▼ │
│ ┌─────────────────────┐ │
│ │ 從溫錢包轉到熱錢包 │ ← 小額補倉，自動化 │
│ │ 或 │ │
│ │ 從冷錢包轉到溫錢包 │ ← 大額補倉，需人工審批 │
│ └──────────┬──────────┘ │
│ │ │
│ ▼ │
│ ┌─────────────────────┐ │
│ │ 等待鏈上確認 │ ← 數十分鐘 ~ 數小時 │
│ └──────────┬──────────┘ │
│ │ │
│ ▼ │
│ hot_balance 回到安全水位 ✅ │
└───────────────────────────────────────────────────────┘
# 虛擬碼
LOW_THRESHOLD = total_assets * 0.02 # 低於 2% 觸發補倉
TARGET_BALANCE = total_assets * 0.04 # 補到 4%
if hot_balance < LOW_THRESHOLD:
amount = TARGET_BALANCE - hot_balance
if amount <= warm_wallet_limit:
transfer_from_warm(amount) # 自動化
else:
request_cold_to_warm(amount) # 需人工審批
alert_ops_team() # 通知運維團隊
實務考量
- 多重簽章或人工審批：冷錢包動用一定要多人簽名，不能一個人搞定
- 補倉延遲：鏈上轉帳需要時間（BTC 可能要 1 小時），所以要提前預測
- 提款尖峰預測：市場大跌時提款量會暴增，需要提前準備
關鍵能力：流動性預測模型——根據歷史數據、市場波動、時間段來預測「接下來幾小時會有多少提款」
六、手續費與提款優化
1. Batch Withdraw（提款併單）
普通模式（每筆獨立上鏈）： 併單模式：
用戶A 提 0.1 BTC → TX1 (手續費) ┌─ 用戶A 提 0.1 BTC ─┐
用戶B 提 0.2 BTC → TX2 (手續費) │ 用戶B 提 0.2 BTC │→ TX1 (一次手續費)
用戶C 提 0.5 BTC → TX3 (手續費) │ 用戶C 提 0.5 BTC │
└────────────────────┘
總手續費：3 筆 總手續費：1 筆（節省 66%）
白話：就像快遞公司不會每收一個包裹就派一臺車，而是等湊夠一車再出發。BTC 原生支援一筆交易帶多個輸出（output），可以大幅降低 Gas 費用。
2. 動態手續費模型
┌───────────────────────────────────────────┐
│ Mempool 擁塞程度監控 │
│ │
│ 低擁塞（< 5 sat/vB） │
│ → 低手續費，慢慢確認就好（1~2 小時） │
│ │
│ 中擁塞（5~30 sat/vB） │
│ → 中等手續費，30 分鐘確認 │
│ │
│ 高擁塞（> 30 sat/vB） │
│ → 高手續費，但仍有上限 │
│ → 超過上限 → 暫時延遲提款 │
│ │
│ 白話：就像計程車跳錶，塞車時費率較高， │
│ 但交易所不會無上限買單 │
└───────────────────────────────────────────┘
3. 提款限速與冷卻
觸發條件 → 效果
─────────────────────────────────────────
變更密碼 → 暫停提款 24 小時
綁定新 2FA 設備 → 暫停提款 24 小時
變更提款白名單地址 → 暫停提款 48 小時
新增 API Key（含提款權限） → 暫停提款 72 小時
白話：如果有人偷了你的帳號、改了密碼，他還是不能馬上把錢提走——因為改密碼後 24 小時內不能提款。這段時間足夠你發現異常、聯繫客服凍結帳號。
七、風控與合規設計
風控全景圖
┌────────────────────────────────────────────────────────────────┐
│ 風控引擎（Risk Engine） │
│ │
│ ┌────────────────┐ ┌────────────────┐ ┌───────────────┐ │
│ │ 事前防禦 │ │ 事中攔截 │ │ 事後追蹤 │ │
│ │ │ │ │ │ │ │
│ │ • KYC 身份驗證 │ │ • 即時風控規則 │ │ • 鏈上追蹤 │ │
│ │ • 地址白名單 │ │ • 異常偵測 │ │ • 事件調查 │ │
│ │ • 設備指紋 │ │ • 人工審查 │ │ • SAR 報告 │ │
│ │ • IP 風險評估 │ │ • 冷卻期機制 │ │ • 帳號凍結 │ │
│ └────────────────┘ └────────────────┘ └───────────────┘ │
│ │
│ ┌───────────────────────────────────────────────────────┐ │
│ │ 地址風險評分系統 │ │
│ │ │ │
│ │ 輸入地址 → 查詢 Chainalysis / Elliptic 等服務 │ │
│ │ → 回傳風險分數 0~100 │ │
│ │ │ │
│ │ 0~30（低風險） → 正常放行 │ │
│ │ 31~70（中風險） → 增加驗證、延遲處理 │ │
│ │ 71~100（高風險）→ 暫停提款、人工審查 │ │
│ │ 黑名單命中 → 直接拒絕、上報主管機關 │ │
│ └───────────────────────────────────────────────────────┘ │
└────────────────────────────────────────────────────────────────┘
提款限制機制
| 用戶等級 | 每日提款上限 | 單筆上限 | 審核方式 |
|---|---|---|---|
| 未驗證 | 0（不可提款） | - | - |
| 基本驗證（L1） | 2 BTC | 1 BTC | 自動 |
| 進階驗證（L2） | 10 BTC | 5 BTC | 自動 + 大額人工 |
| 機構帳戶（L3） | 100 BTC | 50 BTC | 專屬客戶經理 |
八、私鑰控制模式
模式 A：全託管
┌─────────────────────────────────────────────┐
│ 全託管模式 │
│ │
│ 交易所 ──API──→ BitGo │
│ （只能呼叫） （持有全部私鑰） │
│ │
│ 交易所：「請幫我轉 1 BTC 到 xxx」 │
│ BitGo：「好，我簽名後送出」 │
│ │
│ 優點： │
│ ├─ 合規容易（託管方有牌照、有保險） │
│ ├─ 交易所不碰私鑰，內鬼偷不走 │
│ └─ 出事有保險賠 │
│ │
│ 缺點： │
│ ├─ 託管費用高（按資產規模 %） │
│ ├─ 完全依賴第三方（BitGo 掛了你也動不了） │
│ └─ 彈性較低 │
└─────────────────────────────────────────────┘
模式 B：2-of-3 Multi‑sig
┌──────────────────────────────────────────────┐
│ 2-of-3 多重簽名模式 │
│ │
│ 🔑 Key A │
│ 持有者：BitGo（託管方） │
│ 存放：BitGo 安全環境 │
│ │
│ 🔑 Key B │
│ 持有者：交易所 │
│ 存放：交易所的 HSM（硬體安全模組） │
│ │
│ 🔑 Key C │
│ 持有者：備援機構（律師事務所 / 第三方） │
│ 存放：離線安全處 │
│ │
│ 規則：任意 2 把鑰匙就能簽名 │
│ │
│ 正常運作：Key A + Key B 簽名 │
│ BitGo 掛了：Key B + Key C 還能動 │
│ 交易所被駭：只有 Key B，偷不走錢 │
│ │
│ 白話：三個人各拿一把鑰匙， │
│ 要兩個人同時到場才能開保險箱 │
└──────────────────────────────────────────────┘
模式 C：MPC（多方計算）— 進階
┌──────────────────────────────────────────────┐
│ MPC 模式（Multi-Party Computation）│
│ │
│ 🧩 碎片 A → BitGo │
│ 🧩 碎片 B → 交易所 │
│ 🧩 碎片 C → 備援 │
│ │
│ 差異：完整的私鑰「從未存在過」 │
│ 簽名時各方用自己的碎片做計算， │
│ 合成出有效簽名，但沒人看過完整私鑰 │
│ │
│ 優點： │
│ ├─ 比 Multi-sig 更安全（無私鑰重組風險） │
│ ├─ 鏈上看起來像普通交易（省 gas） │
│ └─ 支援任何區塊鏈（不需鏈原生支援多簽） │
└──────────────────────────────────────────────┘
九、Reconciliation（對帳——關鍵控制點）
三方對帳架構
┌───────────────┐ ┌───────────────┐ ┌───────────────┐
│ 交易所帳本 │ │ BitGo 報告 │ │ 鏈上餘額 │
│ (Ledger) │ │ (Custodian) │ │ (On-chain) │
│ │ │ │ │ │
│ Σ 用戶餘額 │ │ 錢包總餘額 │ │ 地址實際餘額│
│ = 1000 BTC │ │ = 1000 BTC │ │ = 1000 BTC │
└───────┬───────┘ └───────┬───────┘ └───────┬───────┘
│ │ │
└───────────────────┼───────────────────┘
│
三者必須相等！
│
┌────────┴────────┐
│ │
相等 ✅ 不等 🚨
│ │
一切正常 ┌─────┴──────┐
│ │
差額 < 容忍值 差額 > 容忍值
(粉塵/手續費) │
│ 立即告警
記錄備查 人工介入調查
對帳頻率建議
| 對帳類型 | 頻率 | 比對內容 |
|---|---|---|
| 即時對帳 | 每筆交易 | 單筆入金/提幣金額正確性 |
| 定時對帳 | 每小時 | 熱錢包餘額 vs 帳本 |
| 全量對帳 | 每日凌晨 | 所有錢包 vs 所有用戶帳本加總 vs 鏈上 |
| 深度審計 | 每月 | 含手續費、粉塵、未確認交易的完整核對 |
若忽略對帳：可能發生的災難——
- 交易所超額放款（帳本顯示的錢比實際多）→ 擠兌時付不出來
- 入金漏記 → 用戶投訴
- 提幣重複執行 → 直接虧錢
- 內部人員私自轉帳 → 無法及時發現
十、主要風險與對策
┌──────────────────┬───────────────────────┬─────────────────────────────┐
│ 風險 │ 解法 │ 白話解釋 │
├──────────────────┼───────────────────────┼─────────────────────────────┤
│ 私鑰被盜 │ Multi-sig / MPC │ 一把鑰匙被偷沒用， │
│ │ │ 要偷到多把才能開鎖 │
├──────────────────┼───────────────────────┼─────────────────────────────┤
│ 內部人員盜領 │ Policy Approval │ 自己人想偷也要過多人審批， │
│ │ + 職責分離 │ 做不到一個人搞定 │
├──────────────────┼───────────────────────┼─────────────────────────────┤
│ 熱錢包被耗盡 │ 提款限速 │ 就算被攻擊也只損失 3~5%， │
│ │ + 低比例配置 │ 大部分錢在冷錢包安全的 │
├──────────────────┼───────────────────────┼─────────────────────────────┤
│ Webhook 偽造 │ HMAC 簽名驗證 │ 每個通知附帶密碼簽名， │
│ │ │ 偽造通知簽名對不上 │
├──────────────────┼───────────────────────┼─────────────────────────────┤
│ 手續費暴漲 │ 動態 Fee 模型 │ 塞車時等一下再出發， │
│ │ + 設定上限 │ 不跟別人搶計程車 │
├──────────────────┼───────────────────────┼─────────────────────────────┤
│ 託管方服務中斷 │ 2-of-3 多簽 │ BitGo 掛了，用備援鑰匙 │
│ │ + 災備方案 │ 還是能把錢轉走 │
├──────────────────┼───────────────────────┼─────────────────────────────┤
│ 區塊鏈重組 │ 高確認數 │ 等足夠多的確認， │
│ (Chain Reorg) │ + 重組偵測告警 │ 就算鏈重組也不受影響 │
└──────────────────┴───────────────────────┴─────────────────────────────┘
十一、大型交易所進階優化
┌─────────────────────────────────────────────────────────────┐
│ 大型交易所進階架構 │
│ │
│ 1. 分鏈獨立 Wallet Cluster │
│ ┌───────┐ ┌───────┐ ┌───────┐ ┌───────┐ │
│ │ BTC │ │ ETH │ │ SOL │ │ ... │ │
│ │Cluster│ │Cluster│ │Cluster│ │ │ │
│ └───────┘ └───────┘ └───────┘ └───────┘ │
│ 白話：每條鏈有自己的錢包叢集，互不影響 │
│ │
│ 2. 熱錢包分片（Sharding） │
│ ┌────┐ ┌────┐ ┌────┐ ┌────┐ │
│ │Hot1│ │Hot2│ │Hot3│ │Hot4│ │
│ └────┘ └────┘ └────┘ └────┘ │
│ 白話：熱錢包拆成多個小錢包，一個被攻擊不影響其他 │
│ │
│ 3. 多區域 RPC 節點 │
│ US-East ←→ EU-West ←→ AP-Southeast │
│ 白話：全球部署節點，哪裡近用哪裡，速度快又有備援 │
│ │
│ 4. 自建 Mempool 監控 │
│ 白話：自己監控待確認交易池，即時掌握手續費行情和 │
│ 可疑交易動態 │
│ │
│ 5. 行為風險 AI 模型 │
│ 白話：用 AI 學習用戶正常行為模式， │
│ 自動偵測異常（如：半夜大額提款、新設備登入） │
│ │
│ 6. 即時流動性壓力測試 │
│ 白話：模擬「如果現在所有人同時提款」的情境， │
│ 確保隨時有足夠流動性 │
└─────────────────────────────────────────────────────────────┘
十二、核心總結
一張圖看懂全架構
用戶
│
┌────┴────────┐
│ 入金 │ 提幣 │
└────┬────────┘
│
┌──────┴──────────┐
│ 交易所 │ ← 帳本 + 風控 + 對帳 + 流動性管理
│ 「決策者」 │
└──────┬──────────┘
│ API
┌──────┴──────────┐
│ BitGo │ ← 私鑰 + 簽名 + 策略 + 錢包管理
│ 「執行者」 │
└──────┬──────────┘
│
┌──────┴──────────┐
│ 區塊鏈 │ ← 不可竄改的公開帳本
│ 「見證者」 │
└─────────────────┘
交易所負責：帳本、風控、資金調度、合規流程 託管方負責：私鑰安全、簽名機制、鏈上交易執行
真正的技術難點
真正的技術難點不在於呼叫 API，而在於：
| 難點 | 為什麼難 |
|---|---|
| 流動性預測 | 要精準預測提款尖峰，提前補倉，不然用戶提不出來 |
| 風險控管 | 要在「不打擾正常用戶」和「攔截可疑交易」之間找平衡 |
| 系統對帳 | 三方資料要即時一致，差一分錢都要查清楚 |
| 災難復原 | BitGo 掛了怎麼辦？鏈分叉怎麼辦？要有 Plan B |
這些能力，才是交易所長期穩定運作的關鍵。