(extensions in package cash.z.wallet.sdk.ext)
Exceptions related to the wallet's birthday.
The data access object for blocks, used for determining the last scanned height.
A collection of tiny logs (twigs) consisting of one trunk and maybe some leaves. There can only ever be one trunk.
Trunks are created by planting a twig. Whenever a leaf sprouts, it will appear as a tag on every log message
until clipped.
Data access object for compact blocks in the "Cache DB."
The "Cache DB", serving as a cache of compact blocks, waiting to be processed. This will contain
the entire blockchain, from the birthdate of the wallet, forward. The CompactBlockProcessor
will copy blocks from this database, as they are scanned. In the future, those blocks can be
deleted because they are no longer needed. Currently, this efficiency has not been implemented.
An implementation of CompactBlockStore that persists information to a database in the given
path. This represents the "cache db" or local cache of compact blocks waiting to be scanned.
Serves as a source of compact blocks received from the light wallet server. Once started, it will use the given
lightwallet service to request all the appropriate blocks and compact block store to persist them. By delegating to
these dependencies, the downloader remains agnostic to the particular implementation of how to retrieve and store
data; although, by default the SDK uses gRPC and SQL.
Responsible for processing the compact blocks that are received from the lightwallet server. This class encapsulates
all the business logic required to validate and scan the blockchain and is therefore tightly coupled with
librustzcash.
Potentially user-facing exceptions that occur while processing compact blocks.
Interface for storing compact blocks.
Since there can only ever be one trunk on the bush of twigs, this class lets
you cheat and make that trunk be a bundle of twigs.
A mined, shielded transaction. Since this is a MinedTransaction, it represents data
on the blockchain.
The "Data DB," where all data derived from the compact blocks is stored. Most importantly, this
database contains transaction information and can be queried for the current balance. The
"blocks" table contains a copy of everything that has been scanned. In the future, that table can
be truncated up to the last scanned block, for storage efficiency. Wallets should only read from,
but never write to, this database.
(extensions in package cash.z.wallet.sdk.ext)
(extensions in package cash.z.wallet.sdk.ext.android)
(extensions in package cash.z.wallet.sdk.ext)
Responsible for initialization, which can be considered as setup that must happen before
synchronizing begins. This begins with one of three actions, a call to either new, import or
open, where the last option is the most common case--when a user is opening a wallet they have
used before on this device.
Exceptions thrown by the initializer.
Exceptions thrown while interacting with lightwalletd.
Implementation of LightwalletService using gRPC for requests to lightwalletd.
Service for interacting with lightwalletd. Implementers of this service should make blocking
calls because async concerns are handled at a higher level.
(extensions in package cash.z.wallet.sdk.ext)
Parent type for transactions that have been mined. This is useful for putting all transactions in
one list for things like history. A mined tx should have all properties, except possibly a memo.
Used in conjunction with the kotlin-allopen plugin to make any class with this annotation open for extension.
Typically, we apply this to classes that we want to mock in androidTests because unit tests don't have this problem,
it's only an issue with JUnit4 Instrumentation tests. This annotation is only leveraged in debug builds.
Manage outbound transactions with the main purpose of reporting which ones are still pending,
particularly after failed attempts or dropped connectivity. The intent is to help see outbound
transactions through to completion.
Example of a repository that leverages the Room paging library to return a PagedList of
transactions. Consumers can register as a page listener and receive an interface that allows for
efficiently paging data.
Data access object providing crud for pending transactions.
Database for pending transaction information. Unlike with the "Data DB," the wallet is free to
write to this database. In a way, this almost serves as a local mempool for all transactions
initiated by this wallet. Currently, the data necessary to support expired transactions is there
but it is not being leveraged.
Facilitates persistent attempts to ensure that an outbound transaction is completed.
The data access object for notes, used for determining whether transactions exist.
User-facing exceptions thrown by the transaction repository.
Serves as the JNI boundary between the Kotlin and Rust layers. Functions in this class should
not be called directly by code outside of the SDK. Instead, one of the higher-level components
should be used such as Wallet.kt or CompactBlockProcessor.kt.
Contract defining the exposed capabilities of the Rust backend.
This is what welds the SDK to the Rust layer.
It is not documented because it is not intended to be used, directly.
Instead, use the synchronizer or one of its subcomponents.
Exceptions thrown in the Rust layer of the SDK. We may not always be able to surface details about this
exception so it's important for the SDK to provide helpful messages whenever these errors are encountered.
Marker for all custom exceptions from the SDK. Making it an interface would result in more typing
so its a supertype, instead.
A Synchronizer that attempts to remain operational, despite any number of errors that can occur.
It acts as the glue that ties all the pieces of the SDK together. Each component of the SDK is
designed for the potential of stand-alone usage but coordinating all the interactions is non-
trivial. So the Synchronizer facilitates this, acting as reference that demonstrates how all the
pieces can be tied together. Its goal is to allow a developer to focus on their app rather than
the nuances of how Zcash works.
This is intentionally insecure. Wallet makers have told us storing keys is their specialty so we don't put a lot of
energy here. A true implementation would create a key using user interaction, perhaps with a password they know that
is never stored, along with requiring user authentication for key use (i.e. fingerprint/PIN/pattern/etc). From there,
one of these approaches might be helpful to store the key securely:
The data access object for sent notes, used for determining whether outbound transactions exist.
Interface for anything that's able to provide signed transaction bytes.
A tiny log that does nothing. No one hears this twig fall in the woods.
(extensions in package cash.z.wallet.sdk.ext)
Primary interface for interacting with the SDK. Defines the contract that specific
implementations like MockSynchronizer and SdkSynchronizer fulfill. Given the language-level
support for coroutines, we favor their use in the SDK and incorporate that choice into this
contract.
High-level exceptions thrown by the synchronizer, which do not fall within the umbrealla of a
child component.
Common interface between confirmed transactions on the blockchain and pending transactions being
constructed.
The data access object for transactions, used for querying all transaction information, including
whether transactions are mined.
Potentially user-facing exceptions thrown while encoding transactions.
Interface for transaction errors.
Repository of wallet transactions, providing an agnostic interface to the underlying information.
A tiny log for detecting troubles. Aim at your troubles and pull the twigger.
A tiny log.
Class responsible for encoding a transaction in a consistent way. This bridges the gap by
behaving like a stateless API so that callers can request createTransaction and receive a
result, even though there are intermediate database interactions.
Wrapper for all the constant values in the SDK. It is important that these values stay fixed for
all users of the SDK. Otherwise, if individual wallet makers are using different values, it
becomes easier to reduce privacy by segmenting the anonymity set of users, particularly as it
relates to network requests.
Wrapper for all the constant values in the SDK. It is important that these values stay fixed for
all users of the SDK. Otherwise, if individual wallet makers are using different values, it
becomes easier to reduce privacy by segmenting the anonymity set of users, particularly as it
relates to network requests.