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

Add test covering deletion of stale ValueStates #142

Closed
wants to merge 2 commits into from

Conversation

afterdusk
Copy link
Member

This PR adds a test verifying that stale ValueState records can be deleted from storage without affecting AKD functionality. The scenario under which this may happen is described in #130 under 1. Stale ValueStates.

@facebook-github-bot facebook-github-bot added the CLA Signed This label is managed by the Facebook bot. Authors need to sign the CLA before a PR can be reviewed. label Feb 9, 2022
let current_azks = akd.retrieve_current_azks().await?;
let root_hash = akd.get_root_hash::<Blake3>(&current_azks).await?;

let history_proof = akd.key_history(&AkdLabel("hello".to_string())).await?;
Copy link
Contributor

Choose a reason for hiding this comment

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

What's the value in the key history proof if the previous values have been deleted? This doesn't return error?

Copy link
Contributor

Choose a reason for hiding this comment

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

I guess in other words, the storage layer is returning GetError("NotFound") or something for some valuestate, and how is the proof still being constructed?

Copy link
Member Author

Choose a reason for hiding this comment

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

From what I can tell, the proof is constructed for the ValueStates that are retrieved. get_user_data would only return the latest ValueState when the previous ones have been deleted, and an update proof is only created for that ValueState.

https://github.com/novifinancial/akd/blob/a409fc284865d4e69d51a218e262dbb94d25ef6e/akd/src/directory.rs#L241-L259

So wouldn't AKD avoid looking up ValueStates that are already deleted and therefore not run into the "NotFound" errors?

Copy link
Contributor

Choose a reason for hiding this comment

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

Hmm OK so that's no ideal. In that case it should be basing the updates off of the state of the node, not the user data retrieved. @Jasleen1 this is a change that will need to occur. There were updates at some epochs, but there just happen to no longer be values associated to those updates.

In the current implementation it's simply stating "there was no change at the given epoch".

let history_proof = akd.key_history(&AkdLabel("hello".to_string())).await?;
let (root_hashes, previous_root_hashes) =
get_key_history_hashes(&akd, &history_proof).await?;
key_history_verify::<Blake3>(
Copy link
Contributor

@slawlor slawlor Feb 9, 2022

Choose a reason for hiding this comment

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

Ah the client isn't presently validating the hash from plaintext_value to leaf value: ref.

Therefore to-date this client verification just assumes the leaf hash IS the hash of the plaintext_value without ever verifying it. @Jasleen1 is that intended or this is to be filled out once VRF's (#122) are included?

At which point I expect this test to fail unless we explicitly add handling support for missing plaintext_value's

Copy link
Member Author

Choose a reason for hiding this comment

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

See reply to above comment - we can also wait for VRFs to be committed before merging this PR.

let lookup_proof = akd.lookup(AkdLabel("hello2".to_string())).await?;
lookup_verify::<Blake3>(root_hash, AkdLabel("hello2".to_string()), lookup_proof)?;

let audit_proof = akd.audit(1, 2).await?;
Copy link
Contributor

Choose a reason for hiding this comment

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

Audit proof shouldn't care, since it (by design) doesn't need the plaintext values to determine a mutation hasn't occurred in history.

Copy link
Member Author

Choose a reason for hiding this comment

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

Yup I am aware, but I was thinking that a test to demonstrate the property couldn't hurt :)

@slawlor
Copy link
Contributor

slawlor commented Feb 10, 2022

I'm OK with shipping this for now, but I think we need @kevinlewi or @Jasleen1 to give some oversight on follow-up to some of the functionality we currently exhibit in this PR.

@kevinlewi
Copy link
Contributor

Thanks for putting this up! Indeed, let's wait for VRF to be landed first

@afterdusk afterdusk closed this Apr 11, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
CLA Signed This label is managed by the Facebook bot. Authors need to sign the CLA before a PR can be reviewed.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants