After block execution we're updating the blockchain state using different transactions for:

• Updating the last block number;
• Setting the canonical block;
• Applying account updates;
• Storing the receipts;
• Storing the block data, with separate commits for:
  • The block number;
  • The block header;
  • The block body;
  • The block difficulty;
  • Updating the latest difficulty;
  • Adding transaction locations;
    And possibly others I may be missing.

This brings two problems:

1. It increases the number of writes to persistent storage (characterized by calls to msync for memory mapped DBs), reducing throughput;
2. It makes recovery in case of shutdown harder, as the transactional guarantees aren't enough to achieve consistency for the latest block processed.

This shows up, at least, on profiles for L1 that import 1000 blocks to an empty chain. In those cases these operations most of the time that the thread is not just waiting on the Tokio runtime.

There are essentially three approaches to improve this:

1. The functional approach: use a closure to represent the work to be done inside the transaction, and make that lambda do all the listed parts;
2. Add .begin, .commit and, possibly, .rollback methods to our storage interface, and use those to mark our transaction bounds properly;
3. Add a wrapper that implements our storage interface that handles this, e.g. by deciding whether to rollback or commit on its Drop implementation.