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

Do not check for root in TrieDB and TrieDBMut constructors #155

Merged
merged 4 commits into from
Apr 8, 2022

Conversation

bkchr
Copy link
Member

@bkchr bkchr commented Apr 8, 2022

This leads to one extra storage lookup before we are doing the actual key lookup. This leads to reading the root twice
when just wanting to lookup one key in the trie. We also return an error on lookup anyway if root doesn't exists, so
there is really no need to do this twice.

This leads to one extra storage lookup before we are doing the actual key lookup. This leads to reading the `root` twice
when just wanting to lookup one key in the trie. We also return an error on lookup anyway if `root` doesn't exists, so
there is really no need to do this twice.
@bkchr bkchr requested a review from cheme April 8, 2022 07:52
@cheme
Copy link
Contributor

cheme commented Apr 8, 2022

I like the idea of not checking root (a trie is valid with any root and should be buildable, then missing is something else).

Probably the initial design was to fail early when state was not available: in system where the presence of root indicate that the whole state for the trie exists (I am thinking maybe previous ethereum code).

Making the function a combination of 'new' and '~check_existing_state'.

Could failing early in substrate be good: we query one node and avoid all processing between triedb instantiation and actual first triedb access. But if the state is correct, we should not have this error ever.
Actually maybe when state is pruned, but then we don't try to sync the block so sounds ok.

Maybe we need to keep the old instantiation for compatibility (changing name and indicating it in the https://github.com/paritytech/trie/blob/master/trie-db/CHANGELOG.md), or add a small 'exists_root' function so previous.
Actually the Changelog could just say: old behavior through 'new' then 'db.contains(..)' check.

@cheme
Copy link
Contributor

cheme commented Apr 8, 2022

Also I did find it inconvenient a few time to have to handle this error, so probably I would suggest adding a good CHANGELOG and this will be good for me.
(also ci failure for bench: two unwrap two remove and rust format needed but that is a detail)

where
L: TrieLayout + 'db,
{
impl TrieFactory {
Copy link
Contributor

Choose a reason for hiding this comment

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

TrieFactory is not used by substrate, but I feel like the change is good to have. Worth mentioning in CHANGELOG though.

Copy link
Member Author

Choose a reason for hiding this comment

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

Here I just removed the warning of the unused layout

Copy link
Contributor

Choose a reason for hiding this comment

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

I mean api did change (better new).


/// `new_with_layout`, but do not check root presence, if missing
/// this will fail at first node access.
pub fn new_unchecked(db: &'db dyn HashDBRef<L::Hash, DBValue>, root: &'db TrieHash<L>) -> Self {
Copy link
Contributor

Choose a reason for hiding this comment

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

Oh we actually have the unchecked version already. I never use it so new being unchecked by default makes sense.
Changelog could simply be new_unchecked replace new.

@cheme cheme requested a review from arkpar April 8, 2022 08:26
@bkchr
Copy link
Member Author

bkchr commented Apr 8, 2022

Actually the Changelog could just say: old behavior through 'new' then 'db.contains(..)' check.

Yeah that sounds reasonable

@bkchr bkchr merged commit f64e1b0 into master Apr 8, 2022
@bkchr bkchr deleted the bkchr-do-not-check-for-root branch April 8, 2022 11:05
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants