Replace RocksDB with Redb as backing for EVM database

[owanikin]

Issue #1845

What was wrong?

The client previously used RocksDB for persistent storage of EVM-related data such as accounts, storage slots, block hashes, and contract bytecode. However, RocksDB has several drawbacks for our use case:

• It’s very slow to compile and bloats build times.
• It’s picky about Rust toolchains and system dependencies.
• It isn’t a truly ACID-compliant database.
• It’s a large C++-based dependency that introduces unnecessary complexity for a Rust-native project.

How was it fixed?

• Replaced RocksDB with Redb, a Rust-native, embeddable ACID key-value store. Redb provides:
• Simpler integration with Rust projects
• Much faster compile times
• Fully ACID-compliant transactions
• A smaller dependency footprint
• The following changes were made:
• Introduced redb::Database as the backing store in EvmDB.
• Defined typed TableDefinitions for each data category (accounts, storage, contracts, block hashes).
• Refactored RocksDB-based put, get, and delete logic into Redb transactional APIs using begin_read and begin_write.
• Updated the .e2ss state import logic, trie operations, and block hash window logic to use Redb.
• Removed all RocksDB-related code and dependencies.
• Added a setup_redb() utility for initializing and opening the database at the configured path.

[KolbyML]

@owanikin can you fix CI and rebase?

[KolbyML]

@owanikin if you need help rebasing or fixing CI just message me on discord and we can jump on a call and fix it quick

[owanikin]

@owanikin if you need help rebasing or fixing CI just message me on discord and we can jump on a call and fix it quick

Thanks @KolbyML . I’ve already rebased the branch and resolved the CI issues — everything should be clean now. Let me know if you need anything else from my end.

[KolbyML]

Hi @owanikin github is still reporting a conflict

you can fix the conflict by running

git fetch upstream
git rebase upstream/master

fix the conflicts

// don't pull
git push --force

[KolbyML]

@owanikin CI is failing again

[owanikin]

@owanikin CI is failing again

@KolbyML CI is passing now.

[morph-dev]

Sorry for the late response, as you might be aware of, there were some changes and Trin is no longer actively maintained.

Therefore I don't think there is much value in reviewing this entire PR, making sure that everything works as expected, and checking if there are some performance degradation.

With that being said, if you don't want all this work to go to waste, I would be fine with creating new branch (redb) and you can create PR to merge the code there (I might do a quick review in the process). Then if Trin is resurrected in the future, somebody can do a proper review and merge that branch into master.

What do you think?

[owanikin]

Sorry for the late response, as you might be aware of, there were some changes and Trin is no longer actively maintained.

Therefore I don't think there is much value in reviewing this entire PR, making sure that everything works as expected, and checking if there are some performance degradation.

With that being said, if you don't want all this work to go to waste, I would be fine with creating new branch (redb) and you can create PR to merge the code there (I might do a quick review in the process). Then if Trin is resurrected in the future, somebody can do a proper review and merge that branch into master.

What do you think?

Thank you @morph-dev , I'll really appreciate that!

[morph-dev]

I created new branch and changed the base branch of this PR. Do you mind rebasing your code (to solve conflicts)?