IX. Storage Module

the storage module of the mova payment public blockchain is responsible for the persistent storage of event data, transaction data, ledger state data, and historical read write sets it serves as the core guarantee for system wide data consistency and traceability this module not only provides high performance write capabilities but also supports flexible data recovery and efficient query mechanisms, ensuring high real time responsiveness and reliability required in payment scenarios 9 1 ledger storage processing flow 9 1 1 event submission and storage process once an event enters consensus, it goes through the following storage procedures write ahead logging (wal) all serialized event data, read write set lists, and the latest event height are first written to the eventbinarylog (the write ahead log), enabling rapid recovery in the event of system exceptions the same data is also written into an in memory cache area to improve overall performance event and transaction data storage the eventdb records the basic information of the event and the list of associated transaction ids, while individual transaction data is stored using the txid as the key a mapping index is created between eventhash and eventheight the latest event height is used as a checkpoint for batch write operations to ensure atomicity state database update the statedb stores the on chain state modified by each transaction, with keys composed of contract name + object primary key like other modules, the database synchronizes at batch intervals using eventheight as the synchronization checkpoint read write set recording historical read write set data is written into historydb , using txid as the primary key these records are used for subsequent queries, auditing, and verification of transaction validity 9 1 2 ledger recovery process if database writes are interrupted due to node failure, the system will enter an automatic recovery procedure during restart independently obtain the latest eventheight from eventbinarylog, eventdb, statedb, and historydb use the eventheight recorded in the wal as the baseline checkpoint to determine whether any databases are in a “lagged state ” if discrepancies exist, replay the missing events and read write sets from the wal and write them into the lagging databases once all database modules have been restored to a consistent height, the system fully starts up and resumes consensus operations 9 1 3 query process query requests first check the in memory cache; if the requested data is not found, it is retrieved from the database for logically deleted data, the cache layer provides deletion markers range queries merge results from memory and disk and deduplicate them to ensure accuracy 9 2 supported database types to meet different deployment needs and business environments, mova supports multiple underlying databases leveldb suitable for lightweight nodes rocksdb supports high concurrency writes, suitable for high performance nodes postgresql / distributed relational databases used for high security, enterprise grade environments requiring horizontal scalability and disaster recovery also used for storing chain tables and synchronizing contract events into relational database structures