Go to file
Kevin Gorham 2c8923290d
Update dependencies.
2020-02-11 20:31:56 -05:00
assets
docs Updated indexes. 2020-01-15 08:15:57 -05:00
gradle/wrapper Update dependencies. 2020-02-11 20:31:56 -05:00
samples/demo-app Add mainnet support. 2020-01-15 07:35:01 -05:00
src New mainnet checkpoints. 2020-02-11 20:10:18 -05:00
.gitignore
Cargo.lock Restore build to working order by removing local-only changes 2020-01-15 09:17:27 -05:00
Cargo.toml Restore build to working order by removing local-only changes 2020-01-15 09:17:27 -05:00
LICENSE
README.md Merge pull request #94 from defuse/link-to-threat-model 2020-01-16 18:12:45 -05:00
build.gradle Update dependencies. 2020-02-11 20:31:56 -05:00
custom-tasks.gradle
gradle.properties
gradlew
gradlew.bat
proguard-rules.pro
settings.gradle
testing.gradle

README.md

This is a beta build and is currently under active development. Please be advised of the following:

  • This code currently is not audited by an external security auditor, use it at your own risk
  • The code has not been subjected to thorough review by engineers at the Electric Coin Company
  • We are actively changing the codebase and adding features where/when needed
  • The code is not yet published (to Bintray/Maven Central)

🔒 Security Warnings

  • The Zcash Android Wallet SDK is experimental and a work in progress. Use it at your own risk.
  • Developers using this SDK must familiarize themselves with the current threat model, especially the known weaknesses described there.

Zcash Android SDK

This lightweight SDK connects Android to Zcash. It welds together Rust and Kotlin in a minimal way, allowing third-party Android apps to send and receive shielded transactions easily, securely and privately.

Contents

Requirements

This SDK is designed to work using a custom block server lightwalletd

Structure

From an app developer's perspective, this SDK will encapsulate the most complex aspects of using Zcash, freeing the developer to focus on UI and UX, rather than scanning blockchains and building commitment trees! Internally, the SDK is structured as follows:

SDK Diagram

Thankfully, the only thing an app developer has to be concerned with is the following:

SDK Diagram Developer Perspective

Back to contents

Overview

At a high level, this SDK simply helps native Android codebases connect to Zcash's Rust crypto libraries without needing to know Rust or be a Cryptographer. Think of it as welding. The SDK takes separate things and tightly bonds them together such that each can remain as idiomatic as possible. It's goal is to make it easy for an app to incorporate shielded transactions while remaining a good citizen on mobile devices.

Given all the moving parts, making things easy requires coordination. The Synchronizer provides that layer of abstraction so that the primary steps to make use of this SDK are simply:

  1. Start the Synchronizer
  2. Subscribe to wallet data

The Synchronizer takes care of

- Connecting to the light wallet server
- Downloading the latest compact blocks in a privacy-sensitive way
- Scanning and trial decrypting those blocks for shielded transactions related to the wallet
- Processing those related transactions into useful data for the UI
- Sending payments to a full node through the light wallet server
- Monitoring sent payments for status updates

To accomplish this, these responsibilities of the SDK are divided into separate components. Each component is coordinated by the Synchronizer, which is the thread that ties it all together.

Components

Component Summary
LightWalletService Service used for requesting compact blocks
CompactBlockStore Stores compact blocks that have been downloaded from the LightWalletService
CompactBlockProcessor Validates and scans the compact blocks in the CompactBlockStore for transaction details
OutboundTransactionManager Creates, Submits and manages transactions for spending funds
Initializer Responsible for all setup that must happen before synchronization can begin. Loads the rust library and helps with key derivation.
RustBackend Wraps the rust library and exposes its functionality to the Kotlin SDK

Back to contents

Quickstart

Add the SDK dependency

implementation "cash.z.android.wallet:zcash-android-testnet:1.0.0-alpha01@aar"

Start the Synchronizer

synchronizer.start(this)

Get the wallet's address

synchronizer.getAddress()

Send funds to another address

synchronizer.sendToAddress(spendingKey, zatoshi, address, memo)

Back to contents

Compiling Sources

⚠️ Presently, the latest stable code lives in the master branch, is under active development, and is not yet released.

Importing the dependency should be enough for use but in the event that you want to compile the SDK from sources, including the Kotlin and Rust portions, simply use Gradle.

Compilation requires Cargo and has been tested on Ubuntu, MacOS and Windows. To compile the SDK run:

./gradlew clean assembleZcashtestnetRelease

This creates a testnet build of the SDK that can be used to preview basic functionality for sending and receiving shielded transactions. If you do not have Rust and Cargo installed, the build script will let you know and provide further instructions for installation. Note that merely using the SDK does not require installing Rust or Cargo--that is only required for compilation.

Back to contents

Versioning

This project follows semantic versioning with pre-release versions. An example of a valid version number is 1.0.4-alpha11 denoting the 11th iteration of the alpha pre-release of version 1.0.4. Stable releases, such as 1.0.4 will not contain any pre-release identifiers. Pre-releases include the following, in order of stability: alpha, beta, rc. Version codes offer a numeric representation of the build name that always increases. The first six significant digits represent the major, minor and patch number (two digits each) and the last 3 significant digits represent the pre-release identifier. The first digit of the identifier signals the build type. Lastly, each new build has a higher version code than all previous builds. The following table breaks this down:

Build Types

Type Purpose Stability Audience Identifier Example Version
alpha Sandbox. For developers to verify behavior and try features. Things seen here might never go to production. Most bugs here can be ignored. Unstable: Expect bugs Internal developers 0XX 1.2.3-alpha04 (10203004)
beta Hand-off. For developers to present finished features. Bugs found here should be reported and immediately addressed, if they relate to recent changes. Unstable: Report bugs Internal stakeholders 2XX 1.2.3-beta04 (10203204)
release candidate Hardening. Final testing for an app release that we believe is ready to go live. The focus here is regression testing to ensure that new changes have not introduced instability in areas that were previously working. Stable: Hunt for bugs External testers 4XX 1.2.3-rc04 (10203404)
production Delivery. Deliver new features to end users. Any bugs found here need to be prioritized. Some will require immediate attention but most can be worked into a future release. Stable: Prioritize bugs Public 8XX 1.2.3 (10203800)

Back to contents

Examples

Examples can be found in the Demo App

Back to contents