1月16日に事故が起き、3月10日になってようやく復旧（復習）レポートが公開された。その53日間、公式はいったい何をしていたのか？これがPost-Mortemを読む前、いちばん大きな疑問でした。

私は復旧レポートのタイムラインをメモに写しました。攻撃は1月16日に発生し、その日のうち（夜の方）にメインチェーン側でブリッジの接続サービスを停止；1月下旬に資金の回収集計と、影響を受けたアドレスの照合が完了；そして3月10日に完全な復旧レポートを公開。$DUSK を写す前に、公開ページの更新タイムスタンプも確認して、途中で中間版が撤回された形跡がないことを確かめました。3つ目まで写していったところで手が止まりました。53日間で公式が状態を更新したのは2回だけで、1回目は事故当日、2回目は復旧レポート公開当日です。

カレンダーに広げて数えてみると、1月16日から3月10日までで53日、更新は2回。平均すると26.5日ごとにようやく動きます。途中の1月下旬に行われた、資金の回収集計とアドレス照合の工程は、すべて復旧レポート内に補足として書かれたもので、その時点で対外的に一言もありませんでした。私はこの53日を4つの枠に分けて整理しました。凍結は時間単位、照合は日単位、根本原因は週単位、復旧レポートと内部審査だけでさらに1か月以上。最初の3枠はすべて空で、最後の枠になってようやく口を開いた。これが私が算出した時間の帳專であり、最初から違和感があった点でもあります。

ただ、4つの枠を広げて考えると、沈黙は不手際（怠慢）を意味しません。@Dusk の「凍結」が時間単位であることは、事故当日にリスクの拡散を断ち切ったことを示し、照合が日単位であることは、取引ごとの突合作業が遅れていないことを意味します。根本原因が週単位であることは、結論に裏づけがあり、思いつきで断じたわけではないことを示しています。どの段階にも明確なアクションがあり、ただ対外更新がなかっただけです。私は最近のいくつかのブリッジ事故での対応も引っ張り出して比較しました。中には事故の翌日にすぐツイートを削除するプロジェクトもあり、半年遅れて詳細のない声明を出すところもあり、あるいはそもそも返答しないところもありました。比較してからは、かえって確信しました。対応プロセスこそが信頼の材料で、この復旧レポートは、その時間線・根本原因・対策をすべて、しかも全て広げて出している数少ない例だからです。

だから私は今、次の一点に注目します。もし次にまた事故が起きた場合、出来事の発生から復旧レポートの公開までの間に、プロセスとしての更新があるのかどうか。更新頻度こそが透明性のものさしです。口でいくら開いていても、タイムスタンプの正直さには勝てません。#dusk