Research: moving block body persist off the apply critical path

[metaphorics]

Question

Block body persist costs 4.18s inside apply; Core pays zero during ConnectBlock because bodies are written to blk files at receipt time, off the validation path. Resolve: (a) confirm Core's actual write path and ordering guarantees (when is a block body durable relative to UpdateTip); (b) what durability invariant bitcoin-rs's apply currently relies on (crash-recovery interaction with the undo/disconnect marker); (c) safe patterns for moving body persist off the apply critical path (write-behind with ordering barrier, persist-at-receive) and what they require of the storage API. Cite primary sources including Core source; note versions.

Part of #16.

[coderabbitai]

🔗 Related PRs

#14 - feat: header timestamp consensus rules, index reorg rollback, mempool policy, fuzz targets [open]

---

📝 Issue Planner

_{Check the box below or use the @coderabbitai plan command to generate an implementation plan and prompts that you can use with your favorite coding assistant.}

• Create Plan

---

🧪 Issue enrichment is currently in open beta.

You can configure auto-planning by selecting labels in the issue_enrichment configuration.

To disable automatic issue enrichment, add the following to your .coderabbit.yaml:

issue_enrichment:
  auto_enrich:
    enabled: false

💬 Have feedback or questions? Drop into our discord!

[metaphorics]

Resolution for Research: moving block body persist off the apply critical path (4.18s): .outline/research/body-persist-off-critical-path.md (with cost detail in .outline/research/block-body-persist-levers.md). Core persists at receipt before ConnectBlock. bitcoin-rs persists synchronously inside apply but does not fsync per block. Persist-at-receive is promising, with an unmeasured 5-7s projection against the current 7.2-8.0s stage and explicit ordering/pruning gates.