Skip to content

WIP store utxo set in the database and not in ram 2 #2159

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

Merged
merged 32 commits into from
Apr 5, 2022

Conversation

tmpolaczyk
Copy link
Contributor

@tmpolaczyk tmpolaczyk commented Mar 3, 2022

This PR stores consolidated entries of the UTXO set in the storage, and the non-consolidated entries in RAM. Consolidated means included in a consolidated superblock.

Close #1275

Warning: this PR makes breaking changes to the storage, so backup before testing.

@tmpolaczyk
Copy link
Contributor Author

Unresolved problem: migrations. Currently the node stores the chain state using the magic number from consensus constants as the key. In this PR, UTXOs are stored without any magic number. This means that the storage cannot be reused by the same node on different testnets, because the old UTXOs will still be marked as valid. So we need to either add the magic number to the UTXO key, as format!("UTXO-{}-{}", magic, output_pointer), or find some way to detect if the environment has changed and delete all the existing UTXOs from the storage (this should now be possible thanks to the iteration support in storage).

This is still unresolved but I think I will just add a check to ensure that there is only one chain state, and panic otherwise.

@tmpolaczyk tmpolaczyk force-pushed the utxo-set-db-2 branch 2 times, most recently from 99321c3 to 9aaed58 Compare March 4, 2022 10:51
@tmpolaczyk tmpolaczyk force-pushed the utxo-set-db-2 branch 2 times, most recently from 9e4e0b3 to 4f90bca Compare March 9, 2022 15:09
@lrubiorod
Copy link
Contributor

lrubiorod commented Mar 10, 2022

I think we should have a discussion before merge this PR due to be a change without backward compatible in the database

@tmpolaczyk tmpolaczyk force-pushed the utxo-set-db-2 branch 2 times, most recently from 2926c6d to ede5917 Compare March 10, 2022 16:20
@tmpolaczyk tmpolaczyk added the breaking change ⚠️ Introduces breaking changes label Mar 15, 2022
@lrubiorod lrubiorod marked this pull request as ready for review March 28, 2022 14:32
@tmpolaczyk
Copy link
Contributor Author

There are some problems when the synchronization process is interrupted, it is possible for the node to become forked and the only way to recover is to use the rewind command. I think it is related to #2102, will keep investigating.

@tmpolaczyk
Copy link
Contributor Author

There are some problems when the synchronization process is interrupted, it is possible for the node to become forked and the only way to recover is to use the rewind command. I think it is related to #2102, will keep investigating.

This is fixed now

@tmpolaczyk
Copy link
Contributor Author

This is still unresolved but I think I will just add a check to ensure that there is only one chain state, and panic otherwise.

This is also implemented now


pub use node_migrations::*;
use witnet_storage::storage::WriteBatch;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

fmt

@@ -3,38 +3,97 @@
//! Storage backend that keeps data in a heap-allocated HashMap.
use std::collections::HashMap;

use crate::storage::{Result, Storage};
use crate::storage::{Result, Storage, StorageIterator, WriteBatch, WriteBatchItem};
use std::sync::{RwLock, RwLockReadGuard};
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

fmt

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
breaking change ⚠️ Introduces breaking changes
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Keep UTXO set in storage
2 participants