Tags: facebook/akd
Tags
Allow Azks parallelism to be configurable (#457) * Simplify append only proof parallelism * Introduce configurable parallelism * Prepare for 0.12.0-pre.11 release * Adopt review suggestions * Re-export parallelism structs at top-level for convenience
Improve NotFound Error Accuracy in key_history (#452) * Improve NotFound Error Accuracy in key_history **Issue** Prior to this patch, the `Directory::key_history` API had potential to return a `HistoryProof` with no `UpdateProof`'s included in it. Considering that `HistoryProof`s can be thought of as an array of `UpdateProof`'s (see: https://docs.rs/akd/0.11.0/akd/struct.HistoryProof.html), the presence of at least one `UpdateProof` is required. The issue detailed above can happen in instances where we perform a read of user states during a publish operation. For example: - The `Directory` has a latest epoch of 10. - A client of AKD performs a read during a publish operation. - `Directory::key_history` reads user states from storage and sees a User U's states with an epoch of 11, indicating that User U has just been added to AKD. - Existing checks which build the `UpdateProof`s to return in the `HistoryProof` filter out the user state associated with epoch 11 since the `Directory`'s latest epoch is only 10. Despite filtering out User U's `ValueState` for epoch 11 correctly (i.e. we cannot include data ahead of the `Directory`), AKD would return a `HistoryProof` containing 0 `UpdateProof`'s. As a result, verification for the `HistoryProof` would fail. **Solution** The solution to the issue mentioned above simply filters out any user's `ValueState`'s which have an epoch greater than the the `Directory`'s current epoch, which then triggers an existing check to return an `AkdError::Storage(StroageError::NotFound)` error. The error more appropriately indicates that the `Directory` does not technically have history for the user yet, at least not until it's latest epoch is updated (via its `aZKS`). **Verfication** To verify that the solution works as intended, we update the `test_errors::test_read_during_publish` test to insert a label which has an epoch greater than the directory's. Prior to including changes made to the directory in this patch, the resultant `HistoryProof` fails to verify due to `UpdateProof`'s not being present: ``` thread 'tests::test_errors::test_read_during_publish_experimental_config' panicked at akd/src/tests/test_errors.rs:269:10: called `Result::unwrap()` on an `Err` value: HistoryProof("No update proofs included in the proof of user AkdLabel([104, 101, 108, 108, 111]) at epoch 2!") note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace [00:00:00.057] INFO No cache found, skipping preload (append_only_zks:651) test tests::test_errors::test_read_during_publish_experimental_config ... FAILED thread 'tests::test_errors::test_read_during_publish_whatsapp_v1_config' panicked at akd/src/tests/test_errors.rs:269:10: called `Result::unwrap()` on an `Err` value: HistoryProof("No update proofs included in the proof of user AkdLabel([104, 101, 108, 108, 111]) at epoch 2!") test tests::test_errors::test_read_during_publish_whatsapp_v1_config ... FAILED failures: failures: tests::test_errors::test_read_during_publish_experimental_config tests::test_errors::test_read_during_publish_whatsapp_v1_config test result: FAILED. 0 passed; 2 failed; 0 ignored; 0 measured; 100 filtered out; finished in 0.05s ``` After the change, we can see that the `Directory::key_history` API not more accruately returns an `AkdError::Storage(StoragerError::NotFound)` error: ``` // History proof for the most recently added key (ahead of directory epoch) should // result in the entry not being found. let recently_added_label_result = akd .key_history(&AkdLabel::from("hello3"), HistoryParams::default()) .await; assert!(matches!( recently_added_label_result, Err(AkdError::Storage(StorageError::NotFound(_))) )); ``` ``` running 2 tests test tests::test_errors::test_read_during_publish_experimental_config ... ok test tests::test_errors::test_read_during_publish_whatsapp_v1_config ... ok test result: ok. 2 passed; 0 failed; 0 ignored; 0 measured; 100 filtered out; finished in 0.03s ``` * Prepare for 0.12.0-pre.9 Release --------- Co-authored-by: Dillon George <dgeo@fb.com>
Prevent Any Storage Errors from Clobbering aZKS Entry (#432) * Prevent Any Storage Errors from Clobbering aZKS Entry **Current** -- Prior to this patch, AKD would incorrectly assume that any error during initialization of a `Directory` should result in an `aZKS` being created and stored in the underlying database implementation. The problem here is that this behavior happened on every error, even those which do not definitively indicate that the read for an `aZKS` passed but a record was not found. For example, if a connection issue occurs when connecting to the storage layer, the current implementation could wrongly overwrite an existing `aZKS`. In such a scenario, the original read for the `aZKS` fails during `Directory` initialization, but a subsequent write succeeds. This can result in clobbered records and unexpected behavior. **Proposed/New** -- With this change, we update the initialization logic for the `Directory` type to only create an `aZKS` if the returned `Err` indicates that the read was successful, but an `aZKS` was not found. In all other instances, we propagate the `Err` back to the caller instead of swallowing it and wrongly creating an `aZKS`. * Prepare for 0.12.0-pre.3 Release --------- Co-authored-by: Dillon George <dgeo@fb.com>
PreviousNext