594枚BTC，因为一个硬件钱包的漏洞没了。
多くの人がこの種のニュースを見ると、まず「ウォレット事業者の責任だ」と反応しますが、システムアーキテクチャの観点から見ると、問題はそれほど単純ではありません。
秘密鍵、署名、認可に関わるあらゆる工程は、取引チェーン全体の中で最も脆弱なノードです。手動取引では秘密鍵は個人が握っているため、リスクは分散され、単一障害点になります。しかし、取引戦略を自動化システムとして展開すると、問題はこう変わります。秘密鍵はどこに保管するのか？ API権限はどう分けるのか？ 署名プロセスにおいて中間者（MITM）が盗み取る可能性はあるのか？
コードを書く人なら誰でも知っている一言があります。「セキュリティは機能ではなく、アーキテクチャだ」。
自動実行されるクオンツ（自動売買）システムでは、APIキーの権限管理は必ず3点を満たさなければなりません。最小権限、タイムリーなコントロール、操作監査。つまり、注文に使うキーは注文しかできず、出金はできない。キーは定期的にローテーションし、長期間有効にしない。そして、すべての署名リクエストにはログを残し、異常な呼び出しは検知して遮断できるようにするのです。
こうした問題へのプログラム側の処理ロジックは、人とは違います。
人は自覚と慎重さに頼り、プログラムはルールと検証に頼るのです。設計の合理的なクオンツシステムでは、毎回の取引実行前に署名元を検証し、指示の完全性をチェックし、目的のアドレスがホワイトリストに含まれていることを確認します。これは「おまけ」ではなく、システムを本番稼働させるための前提条件です。
594枚BTCを失った教訓は何か？
「そのウォレットを使うな」ではありません。「あなたの取引システムの安全アーキテクチャが、どれだけ徹底されているか」です。

#Coldcard #量化交易 #API安全 #风险管理 #程序化交易