ADAMANTノードは、派生したmem_*状態の永続化されローテーション可能なチェックポイントをサポートするようになりました。強制的に中断され、メモリミラーが不整合になった場合、起動時に最新の検証済みチェックポイントを復元し、高さ1からのすべてのメモリテーブルの再構築ではなく、チェックポイント高さ以降のブロックのみをリプレイすることで復旧できます。これは、issue #227 で設計され、pull request #261 でマージされた仕様を実装したものです。チェックポイントはローカルなリカバリキャッシュに過ぎず、ブロックと決定論的リプレイが依然として信頼できる情報源です。検証またはリプレイが失敗した場合、ノードは既存の完全な再構築パスにフォールバックします。
書き込み処理中にプロセスが強制終了された場合、mem_accounts、mem_round、委任およびマルチシグ接合テーブル、およびそれらの未確認ミラーなどの派生テーブルが不整合になる可能性があります。引き続きSIGTERMによるグレーシャルシャットダウンが推奨される運用方法ですが、強制終了が発生した場合のリカバリ時間をチェックポイントによって短縮できます。
この実装では、メタデータテーブル（mem_state_checkpoint_meta）と、確定状態用の3つのローテーションスロットテーブルセット（mem_ckpt_0..2_*）を導入しています。未確認の接合テーブルはチェックポイント対象外であり、復元時に確定状態から再構築されます。コアロジックは、ダイジェストとスロットローテーションを担当するlogic/memCheckpoint.js、モジュールラッパーとしてのmodules/memCheckpoints.js、SQLヘルパーを提供するsql/memCheckpoints.js、およびリカバリとチェックポイント作成をトリガーするmodules/loader.jsとmodules/blocks/chain.jsの変更に分割されています。
チェックポイントは、applyBlockパイプライン全体がブロックを永続化した後の完了したラウンド境界でのみ作成されます。チェーンの先端では、これは各完了ラウンドごとに発生します。キャッチアップ同期中は、同期スループットを低下させないよう、100ラウンドごとに発生します。チェックポイント作成にはPostgreSQLのREPEATABLE READトランザクションを使用してMVCCスナップショットを固定します。メタデータ行の永続化が完了すると直ちにブロック処理のクリティカルセクションは解放され、テーブルのコピーとダイジェスト計算は固定されたスナップショットに対してバックグラウンドで継続されます。これにより、コピー操作全体の間クリティカルセクションを保持するのを回避しています。
リカバリ用にチェックポイントが受け入れられる前に、いくつかの不変条件がチェックされます：ステータスが完了であること、スキーマとnethashが一致すること、参照されるブロックが存在すること、SHA-256ダイジェストが一致すること。リカバリは、最新の完全なスロットから順に試行するため、最新スロットが破損していても、古い有効なスロットが存在すれば完全な再構築を強制されることはありません。起動時にcheckMemTables()が不整合を検出した場合、memCheckpoints.tryRecover()はスロットを復元し、未確認状態をリセットし、最終ブロックをシードして、チェックポイント高さから先端までのブロックをリプレイします。リプレイが失敗した場合、ノードはチェックポイント状態を破棄し、ジェネシスから完全な再構築を実行します。
この機能はconfig.default.jsonでデフォルトで有効になっています：
"loading": {
"memCheckpoints": {
"enabled": true
}
}運用者は、これがプロトコルの変更を伴わないことに注意してください。チェックポイントは決して合意形成の入力にはならず、改ざんされたローカルデータがブロック検証をバイパスすることはありません。メインネット規模のmem_*フットプリントでは、3つのスロットでメタデータを含めて約96～144 MBを必要とするため、約1 GBの余裕を確保することを推奨します。チェックポイントはリカバリ時間を短縮しますが、適切なシャットダウン手順に代わるものではないため、運用者は引き続きグレーシャルシャットダウンを優先すべきです。