Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat: update blockchain state in a single transaction #1995

Open
Oppen opened this issue Feb 18, 2025 · 0 comments
Open

feat: update blockchain state in a single transaction #1995

Oppen opened this issue Feb 18, 2025 · 0 comments

Comments

@Oppen
Copy link
Contributor

Oppen commented Feb 18, 2025

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.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Status: No status
Development

No branches or pull requests

1 participant