Skip to content

feat(wallet-lib): do not sync transactions if mnemonic is absent#7

Merged
shumkov merged 1 commit into
v0.22-devfrom
feat/do-not-sync-in-abscence-of-mnemonic
Nov 3, 2021
Merged

feat(wallet-lib): do not sync transactions if mnemonic is absent#7
shumkov merged 1 commit into
v0.22-devfrom
feat/do-not-sync-in-abscence-of-mnemonic

Conversation

@jawid-h
Copy link
Copy Markdown
Contributor

@jawid-h jawid-h commented Nov 3, 2021

Issue being fixed or feature implemented

This change eliminates unnecessary synchronization of transactions in case wallet has been generated from the new mnemonic

What was done?

Check if the wallet has been generated from the new mnemonic and sync transactions from the best block (instead of block 1 or the one provided via unsafeOptions: { skipSynchronizationBeforeHeight: <n> })

How Has This Been Tested?

  • Passed no mnemonic to the Wallet initialization arguments
  • Ensured quick initialization time
  • Hooked on account events and ensured that synchronization of the new blocks works properly

Breaking Changes

Checklist:

  • I have performed a self-review of my own code
  • I have commented my code, particularly in hard-to-understand areas
  • I have added or updated relevant unit/integration/functional/e2e tests
  • I have made corresponding changes to the documentation

For repository code-owners and collaborators only

  • I have assigned this pull request to a milestone

@jawid-h jawid-h added this to the v0.22.0 milestone Nov 3, 2021
@shumkov shumkov merged commit 7d14553 into v0.22-dev Nov 3, 2021
@shumkov shumkov deleted the feat/do-not-sync-in-abscence-of-mnemonic branch November 3, 2021 15:08
shumkov pushed a commit that referenced this pull request Nov 23, 2022
feat: type deserialization + encoding
QuantumExplorer added a commit that referenced this pull request Mar 16, 2026
- Delete fake tests in make_sure_core_is_synced_to_chain_lock/v0 that
  never called the production method (CRITICAL #1)
- Delete fake tests in verify_chain_lock_through_core/v0 that only
  exercised mock wiring, never the production method (CRITICAL #2)
- Add real tree verification in protocol_upgrade tests: v12 now checks
  shielded pool, notes, nullifiers, and anchors trees (MAJOR #3)
- Fix get_contract_with_fetch_info_and_fee assertion to verify the
  contract is Some, not just Ok (MEDIUM #4)
- Rename test_transition_from_version_10 and add actual verification
  of v11/v12 artifacts (LOW #5)
- Replace bare .unwrap() with .expect() in choose_quorum tests (LOW #6)
- Remove empty-input smoke test for store_address_balances (LOW #7)
- Fix test_decode_state_transition_at_exact_max_size to assert the
  correct property (not rejected as oversized) rather than incorrectly
  assuming zeros cannot decode

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
QuantumExplorer added a commit that referenced this pull request May 14, 2026
…iagrams

New chapter under "Drive" that walks through the bench fixture's
widget contract and shows what each count-query proof actually
proves — both the path query the prover signs AND the verified
element the verifier extracts. Every example is reproducible
against the existing bench at
`packages/rs-drive/benches/document_count_worst_case.rs`.

Seven worked examples (the `group_by = []` proof surface):

1. `(empty)` — primary-key CountTree fast path, 585 B.
2. `brand == X` — PointLookup over byBrand (plain countable),
   1,041 B post-v12 (the value-tree-direct shape now activates
   for any countable terminator, not just rangeCountable).
3. `color == X` — PointLookup over byColor (rangeCountable),
   1,327 B. Same shape as #2 — the rangeCountable flag is only
   relevant for #7.
4. `brand == X AND color == Y` — PointLookup over byBrandColor;
   the proof descends through the byBrand value tree's
   `NonCounted`-wrapped `color` continuation to the byBrandColor
   terminator, 1,911 B.
5. `brand IN [b0, b1]` — outer Keys per In value, no subquery
   (the value-tree-direct shape on the In axis), 1,102 B.
6. `color IN [c0, c1]` — identical shape to #5, surfacing the
   v12 generalization at a glance: byBrand (plain countable)
   and byColor (rangeCountable) produce structurally identical
   proofs, 1,381 B.
7. `color > floor` — AggregateCountOnRange over byColor's
   ProvableCountTree; different verifier
   (`verify_aggregate_count_query`), single u64 result, 2,072 B.

Each section has three parts:

- **Path query** (decoded path + items + subquery), the prover's
  spec.
- **Verified element / payload** (the structured output of
  `verify_query`/`verify_aggregate_count_query`).
- **Mermaid diagram** with:
  - The tree element wrapper for the relevant GroveDB subtree.
  - Blue arrows tracing the descent.
  - A cyan target node for the verified element.
  - Faded nodes for context.

A "GroveDB Layout" diagram up front shows the storage shape for
the whole contract (doctype CountTree primary key, byBrand
NormalTree property-name with CountTree value trees and
NonCounted-wrapped byBrandColor continuations, byColor
ProvableCountTree property-name with CountTree value trees).
Each per-query diagram is a focused slice of this overview.

An at-a-glance comparison table at the end summarizes primitive
choice, verified shape, and proof size across all seven examples
to make the structural symmetry between #2/#3 and #5/#6 (post-v12
generalization) and the asymmetry of #7 (AggregateCountOnRange)
visually obvious.

Registered under `Drive` in `SUMMARY.md` immediately after the
existing `Document Count Trees` chapter, which it complements
(that chapter explains the tree variants in the abstract; this
one shows how queries traverse the resulting layout). Builds
cleanly via `mdbook build` against the existing
`mdbook-mermaid` preprocessor configuration.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
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.

2 participants