Post-Mortem Report

What is a post-mortem report, and how does it differ from a platform's general announcement?

A post-mortem report is a structured, formal document that typically includes several fixed elements: a precise incident timeline (every point from the earliest anomaly signal, to discovery, to the response measures taken), root cause analysis (not just what happened, but why it happened), scope of impact (how many users were affected, actual loss amount), and specific remediation and prevention measures (how to avoid the same type of incident recurring). This level of structure goes far beyond a general announcement that just says something vague like "we've noticed an anomaly and are investigating."

A general announcement's purpose is usually to reassure users and buy time to handle the situation; a post-mortem report's purpose is to provide enough technical and process detail for the outside community (including potential users, auditors, and peers) to independently verify whether the team genuinely understood the root cause and took substantively effective measures, rather than just performing crisis PR.

事後検証レポートはなぜDeFAI業界にとって特に重要なのですか？従来のテクノロジー業界のインシデントレポートとどう違いますか？

従来のテクノロジー業界のインシデントレポート（ウェブサイトのダウンなど）は通常サービスの中断だけを伴い、ユーザーの実際の資産が直接損害を受けることは一般的にない。一方、DeFAI業界のインシデントは、しばしばユーザー資金の実際の損失に直接等しく、オンチェーン取引は一度確定すると、ほとんどの場合覆すことができない。これは、DeFAIの事後検証レポートがより重い責任を負うことを意味する——単に「なぜサービスが中断したか」を説明するだけでなく、しばしば「ユーザーのお金に実際何が起きたのか、回収の可能性はあるのか」も説明する必要がある。

もう一つの重要な違いは検証可能性である。ブロックチェーン取引は公開検証可能であるため、事後検証レポートに記載されたタイムラインと資金の流れは、理論上誰でもオンチェーンデータと照らし合わせて独立して確認できる。これは従来のテクノロジー業界のインシデントレポート（ユーザーは通常、企業の内部システムログの真実性を検証する能力を持たない）とは異なる。これが、DeFAI業界においてレポートの内容が実際のオンチェーン記録と一致しているかどうか自体が、そのレポートの信頼性を判断する重要な根拠となる理由である。

質の高い事後検証レポートには実際どんな具体的な要素が必要ですか？

完全なタイムラインは最も基本的な要素であり、具体的なタイムスタンプと対応するオンチェーン取引ハッシュ値を含めるべきである。これにより読者は自分でブロックチェーンエクスプローラーに行き、主張されている各イベントが実際に起きたかを確認できる。根本原因分析では技術面の直接的な原因（検証ロジックのどの行のコードに脆弱性があったかなど）を明確に説明する必要があり、できればプロセス面の間接的な原因（この脆弱性がなぜ監査段階で発見されなかったか）もカバーするのが望ましい。技術的な原因だけを語り、プロセス上の欠陥について触れないレポートは、通常反省の深さが不十分であることを示す。

是正措置の部分では、「既に完了した修正」と「今後行うと約束したこと」を明確に区別する必要がある点に注意すべきである——完了した部分には検証可能な証拠（新しいコントラクトのデプロイアドレス、監査レポートへのリンクなど）を添付すべきであり、約束されている部分には曖昧な「継続的に改善していきます」ではなく、明確なスケジュールが必要である。さらに、正直なレポートは通常、チーム自身のプロセスや判断の誤りを率直に認めるものであり、責任を完全に「予測不可能な外部からの攻撃」に転嫁するものではない。一部の責任を引き受ける意欲のあるレポートは、通常、全てを外部要因に帰するレポートよりも信頼に値する。

事後検証レポートは一般ユーザーにどのような実際の影響を与えますか？この文書をどう活用して判断すればよいですか？

過去にインシデントを経験したことのあるDeFAI製品を評価している場合、この事後検証レポート自体が最も直接的なデューデリジェンスの材料となる——「インシデントが起きたかどうか」自体を見るのではなく（どれだけ厳密なシステムでも未知の攻撃に遭遇する可能性はある）、「インシデント後にこのチームがどう対応したか」を見る。詳細なタイムラインを公開し、根本原因を正直に認め、具体的で検証可能な是正措置を示す意欲のあるチームは、たとえインシデントが発生していても、長期的には一度も問題を公に認めたことがないが同様の未発見のリスクを抱えている可能性のあるチームよりも、信頼に値することがある。

実際に判断する際は、いくつかの質問を自分にしてみるとよい：このレポートはオンチェーンデータと照合できるほど具体的か、根本原因分析は表面にとどまっていないか（単に「ハッキングされた」とだけ言って攻撃経路を説明していないなど）、是正措置には検証可能な証拠が添付されているか漠然とした約束にとどまっていないか、レポートの公開時期はインシデント発生から合理的な期間内か（数ヶ月遅れて公開された、あるいはレポートの内容が明らかに重要な点を回避しているなどは、いずれも警戒を強めるべきシグナルである）。