-
Notifications
You must be signed in to change notification settings - Fork 0
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
- Loading branch information
Showing
4 changed files
with
70 additions
and
63 deletions.
There are no files selected for viewing
64 changes: 64 additions & 0 deletions
64
src/factor_instance_provider/cache/is_pre_derived_keys_cache.rs
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,64 @@ | ||
use crate::prelude::*; | ||
|
||
/// A cache for pre-derived keys, saved on file and which will derive more keys | ||
/// if needed, using UI/UX via KeysCollector. | ||
/// | ||
/// We must implement the `FactorInstanceProvider` in a way that it can handle | ||
/// the case where the cache does not exist, which it does not for users before | ||
/// Radix Wallet version 2.0. | ||
/// | ||
/// The purpose of this cache is only to speed up the process of accessing | ||
/// FactorInstances. | ||
#[async_trait::async_trait] | ||
pub trait IsPreDerivedKeysCache { | ||
/// Inserts the `derived` keys into the cache, notice the asymmetry of this | ||
/// "save" vs the `consume_next_factor_instances` ("load") - this method accepts | ||
/// a set of factors per request, while the `consume_next_factor_instances` | ||
/// returns a single factor per request. | ||
/// | ||
/// The reason is that we are deriving many keys and caching them, per request, | ||
/// whereas the `consume_next_factor_instances` ("load") only ever cares about | ||
/// the next key to be consumed. | ||
async fn insert( | ||
&self, | ||
derived: IndexMap<PreDeriveKeysCacheKey, IndexSet<HierarchicalDeterministicFactorInstance>>, | ||
) -> Result<()>; | ||
|
||
/// Must be async since might need to derive more keys if we are about | ||
/// to use the last, thus will require usage of KeysCollector - which is async. | ||
/// Also typically we cache to file - which itself is async | ||
async fn consume_next_factor_instances( | ||
&self, | ||
requests: IndexSet<DerivationRequest>, | ||
) -> Result<IndexMap<DerivationRequest, HierarchicalDeterministicFactorInstance>>; | ||
|
||
/// Returns `NextDerivationPeekOutcome::WouldHaveAtLeastOneFactorLeftPerFulfilledRequests` | ||
/// if there would be **at least on key left** after we have consumed | ||
/// (deleted) keys fulfilling all `requests`. Otherwise returns | ||
///`NextDerivationPeekOutcome::WouldConsumeLastFactorOfRequests(last)` where `indices` is a map of the last consumed indices | ||
/// for each request. By index we mean Derivation Entity Index (`HDPathComponent`). | ||
/// If there is any problem with the cache, returns `Err`. | ||
/// | ||
/// We **must** have one key/factor left fulfilling the request, so that we can | ||
/// derive the next keys based on that. | ||
/// This prevents us from a problem: | ||
/// 1. Account X with address `A` is created by FactorInstance `F` with | ||
/// `{ factor_source: L, key_space: Unsecurified, index: 0 }` | ||
/// 2. User securified account `X`, and `F = { factor_source: L, key_space: Unsecurified, index: 0 }` | ||
/// is now "free", since it is no longer found in the Profile. | ||
/// 3. User tries to create account `Y` with `L` and if we would have used | ||
/// Profile "static analysis" it would say that `F = { factor_source: L, key_space: Unsecurified, index: 0 }` | ||
/// is next/available. | ||
/// 4. Failure! Account `Y` was never created since it would have same | ||
/// address `A` as account `X`, since it would have used same FactorInstance. | ||
/// 5. This problem is we cannot do this simple static analysis of Profile | ||
/// to find next index we would actually need to form derivation paths and | ||
/// derive the keys and check if that public key has been used to create any | ||
/// of the addresses in profile. | ||
/// | ||
/// Eureka! Or we just ensure to not loose track of the fact that `0` has | ||
/// been used, by letting the cache contains (0...N) keys and **before** `N` | ||
/// is consumed, we derive the next `(N+1, N+N)` keys and cache them. This | ||
/// way we need only derive more keys when they are needed. | ||
async fn peek(&self, requests: IndexSet<DerivationRequest>) -> NextDerivationPeekOutcome; | ||
} |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,3 @@ | ||
mod is_pre_derived_keys_cache; | ||
|
||
pub use is_pre_derived_keys_cache::*; |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters