MIMD 0008 Reevaluation of storage of account data modifications

[bmuddha]

Proposal: Revisiting Account Data Modification Persistence in MagicBlock Validator

Background

The MagicBlock validator introduces a unique mechanism for account management: selective, on-demand cloning of accounts from the base Solana chain. This ensures that all accounts required by any transaction executed on the MagicBlock validator are present and up-to-date before execution.

Currently, the Solana Virtual Machine (SVM) facilitates this cloning process. Account insertions and updates to AccountsDB are performed via standard Solana transactions. This approach serves two primary purposes:

1. Auditability: Enables comprehensive tracing of account modification history, including changes that originated on-chain and were never directly modified by the MagicBlock validator.
2. Verifiability and Replayability: By recording all account states as they existed during transaction execution, the system supports reliable ledger replay and verification.

Current Challenges

Despite its benefits, the current implementation faces several limitations:

• Transaction Encoding Limitations: Not all account states can be encoded within a single transaction, necessitating an additional layer of indirection.
• Stashing Mechanism: To address this, account states to be written to AccountsDB are temporarily "stashed" in memory (and in the RocksDB ledger). These states are later extracted and applied during transaction execution via a built-in program capable of bypassing the SVM's sandboxing restrictions.
• Complexity and Overhead: This design introduces several issues:
  1. Custom Sandbox Escape Logic: Special logic is required to circumvent SVM sandboxing, increasing code complexity and maintenance burden.
  2. Convoluted Data Flow: The stashing mechanism complicates the control and data flow, making the system harder to reason about and debug.
  3. Resource Inefficiency: Writing to the ledger incurs non-trivial CPU and disk usage costs, impacting overall system performance.

Motivation for Change

As part of the ongoing ledger rewrite initiative (MIMD-0007), it is timely to reevaluate the current approach to handling account data modifications. The goals are to:

• Simplify Control and Data Flows: Reduce system complexity by eliminating unnecessary indirection and custom logic.
• Improve Performance: Minimize CPU and disk overhead associated with account state persistence.
• Enhance Transaction Throughput: Streamline account data handling to support higher transaction volumes and lower latency.

Proposed Direction

We propose a comprehensive review and redesign of the account data modification persistence mechanism within the MagicBlock validator. Key considerations include:

• Direct Account State Management: Explore alternatives to the current stashing and extraction process, potentially enabling more direct and efficient updates to AccountsDB.
• Sandboxing Model Reassessment: Investigate whether the need for custom sandbox escape logic can be eliminated
• Maintain Auditability and Replayability: Ensure that any new approach continues to support full traceability and reliable ledger replay.

Potential solution

One possible solution might be to use account state diff, which is encoded in transaction itself. Considering that accounts in solana are small on average, and state diffs are even smaller, then it's safe to assume that in most cases that diff can be encoded into a single transaction. This has several advantages:

1. No need to stash anything, the entire state necessary for transaction execution is already included in transaction itself
2. Smaller size of data written to the ledger, as most of the diffs can be encoded in less than 100 bytes.
3. Faster transaction execution due to absence of extra stashing/extraction steps

In rare cases when state diff exceeds the transaction size limit, it can be split between multiple transactions, which will run in sequence before any other transaction that refers to the account in question.