保管された黄昏（ダスク）のイベントは、起きなかった状態変化を説明しうる

バックエンドは、黄昏（ダスク）の確定アーカイブからイベントを読み取っても、誤った財務判断を下してしまう可能性があります。

Boreas がリスタートブロック 4,414,095 でメインネット上で有効化されて以来、Dusk は意図的に、アーカイブデータ内で復元（reverted）されたコントラクトイベントを復元マーカー付きで保持しています。これらのイベントは、実行によって生成されたという歴史的証拠であって、その状態効果が維持されたことの証明ではありません。

Post-Boreas では、復元されたイベントはカノニカルなブロックブルームから除外され、復元されたステークイベントは provisioner の状態を更新しません。

この違いは、イベントがデータベースの更新（ミューテーション）へと変換される場面で重要になります。「イベントが存在する」ことを「操作が成功した」とみなすインデクサは、預け入れにクレジットしたり、支払い（payout）を記録したり、連鎖して下流のロジックを起動したりしてしまうことがあります。これは、チェーンがロールバックした状態に対して行われる可能性があります。

Dusk 自身の Moonlight 入金ガイダンスでは、このルールは明確です。直接入金は、送金イベントが期待される操作と一致し、かつ event.reverted === false のときのみ受け付けられます。

つまり、確定（finalization）は 1 つの問いに答えるだけです。アーカイブされた履歴は決着済みか？ それは、その履歴が何を語っているのかを解釈する必要を消し去るものではありません。

Boreas 後の Dusk 統合では、reverted は無視すべきメタデータではありません。過去の実行の証拠とカノニカルな状態を切り分ける受け入れ条件の一部です。

@Dusk $DUSK #dusk