Having finished work on ZeWIF, Blockchain Commons is looking to continue to work with the Zcash ecosystem. What follows are some new projects we are considering, all of which we think are a bit closer to our core expertise, as they largely focus on expanding our existing work to the Zcash ecosystem. We’d love your input on what you find important. Assuming something seems to have critical mass, we expect to write a full grant request for the project next week.
I should note that Blockchain Commons is a developer support organization, not a software wallet publisher. Our goal is to provide resources for wallet developers. We work closely with them to polish specs and even to integrate specs into their products, but our ultimate goal is to make tools available for the entire ecosystem. This work includes specifications, libraries that allow the use of those specs, and CLI and GUI reference apps that demonstrate their usage. We have had considerable success doing this in the Bitcoin ecosystem and want to bring our expertise to ZCash wallet developers.
For the projects outlined here we may be creating new specs, libraries, or reference apps or extending currents ones to better integrate with the Zcash ecosystem and/or providing support for use with Android systems (as we are mostly focused on iOS at the moment).
Our ultimate goals are embodied in what we call the Gordian Principles, which include privacy, independence for users, resilience for data, and openness for the ecosystem. That’s what we hope to bring to (or really to expand) for Zcash.
Here’s some of the projects we’re considering. Are there ones you like? Don’t like? Think are best? Are there privacy/resilience/openness/independence options we’re not considering that you’d like to see.
Let us know!
- DEVELOPER INTEROP MEETINGS.
- Goal: Improve developer knowledge.
- Requirements: Developers willing to attend.
Our simplest option is to support the developer community with focused meetings that will talk about our available specs, what they really mean, and how to integrate them. We always log and document our meetings so they’re also useful for future developers.
Things we’d like to work with the Zcash community on include: ZF FROST; an intro to Blockchain Commons interop specs; multisig vs Shamir; and ZeWIF. I expected we’d lay this out as six meetings over the course of a year, and it’d hopefully help uncover those things the community wants to see more of – things where developers are already buying in to their own support of the work.
- RESILIENCE RAMP-UP.
- Goal: Make it harder to lose Zcash (and especially seeds/keys)
- Requirements: One or two wallet companies willing to work with us (we likely already have one)
One of Blockchain Commons’ biggest initiatives for years has been what we call “Smart Custody”, which is focused on making it easier for people to maintain control of their digital assets, without fear of loss (which is a much greater danger than theft for the average holder). Here, we lay out how we’d bring our entire resilience stack to Zcash. We could limit this, to only continue up to a specific step, if the community felt like they’d like to see just that much work as a first phase, so if you find some but not all of this important, let us know (or let us know if you’d like to see all of it!).
-
A. SSKR. We store keys and seeds in Gordian Envelopes locked with Shamir’s Secret Sharing. Shares can then be distributed to improve resilience and reduce chances of compromise. Envelope SSKR allows storage of multiple & large secrets, with corresponding metadata for identification. These shares can be printed out or stored to NFCs or microSDs.
(See our SSKR pages.) -
B. GSTP. We provide full integration for our Gordian Envelope-based “Sealed Transaction Protocol”. This can immediately allow new methodologies for storage of secrets over Bluetooth or other insecure transit methods. (We worked with Foundation in the Bitcoin ecosystem system to enable this for their new Passport Prime hardware wallet.) It also is crucial for later phases. Finally it also supports the creation of a spec for secure P2P purchase orders, invoices, and payment receipts, to allow a methodology for privately and securely requesting funds, to match the privacy and security of shielded transactions. (GSTP Invoices could even be broken out as separate project if the entire resilience stack is not desired at this point. (See our GSTP pages.)
-
C. WALLET CROSS-SHARE. We provide support for being able to store shares of a secret on other wallets. (You shard with SSKR, then you exchange with GSTP.) The object is to have your seed/key securely stored in other places, but since they’re shares, those other places can’t access your actual secret.
-
D. ROUGH VERIFIABILITY. We spec & develop a rough way to ensure verifiability of shares, so that a remote wallet can show that they still have access to the share. (We currently use Shamir, but without a full VSS support, below, this system could be subject to malicious faking resulting in denial, but resolves the more common issue of loss of share by a good actor.)
-
E. VSS. We expand our SSKR library to also support Verifiable Secret Sharing (VSS), which allows for a much more robust verifiability. This is also a stepping stone to FROST, which also uses VSS. FROST itself is not part of this resilience stack, but it may be useful for the future.
-
(To this point, this system allows robust & verifiable interchange of shares among wallets, allowing any wallet developer to provide resilient backups as long as a user has [usually] two or more other wallet users that they can exchange shares with.)
-
F. CSR. The next step in seed resilience is “Collaborative Share Recovery”. This allows for the creation of “share servers” on the internet that can store shares, rather than depending on them being held in other wallets. It has a higher requirement, because it needs a long-term commitment from at leasta two organizations to host these share servers. But the end result is a dramatically improved system of resilience, where shares are automatically stored and recovered from reliable online servers as needed. (See our CSR page.)
- Passkeys.
- Goal: Provide an alternative methodology for accessing seeds & keys
- Requirements: One or two wallet companies willing to work with us (we likely already have one)
We prefer our resilience stack as outlined above, as we think it provides a methodology with verifiability and future-proofing that make it likely that secrets will be recoverable well into the future. However, we know that the accessibility of passkeys is currently winning a lot of converts.
We would develop a spec for using webauthn and passkeys to encrypt access to Zcash secrets and data and would provide libraries to make this available to wallet developers.
We currently have a proof-of-concept of this where we use SSH Keys to encrypt Gordian Envelopes, which is architecturally close to WebAuthN. Nonetheless, this would be more of a proof-of-concept project than the ones directly building on our current specs. However, it’d be a great new tool for our toolbox and that of wallet developers, so we’re interested in it.
- OIB.
- Goal: Make it easier for users to identify digital assets
- Requirements: One or two wallet companies willing to work with us (we likely already have one)
Blockchain Commons has developed a UX standard for the “Object Identity Block” to provide a visual hash and a standardized block of information to identify any seed or key. It allows a user to viscerally identify a seed, keys, or addresses at a glance. This makes it easy to see what seed, key or address is being used for a payment, therefore increasing privacy and decreasing fraud.
We would work to specialize aspects of the OIB for Zcash (e.g., by better identifying transparent vs. shielded addresses) and then make it more easily available to wallet developers. (See our OIB pages.)
- LEARNING ZCASH.
- Goal: Bring new developers into the Zcash community!
- Requirements: a good CLI (probably)
Our Learning Bitcoin from the CLI course has been very successful over the years. It’s not only generated considerable interest on GitHub (3,300 stars, 800 forks), but we also know Bitcoin developers that it’s brought into the industry. We’d like to do the same for Zcash.
The concept is simple: a hands-on course that teaches what Zcash is and teaches new developers how it works through lessons that are interwoven with actual usage via a command-line interface. We expect the Zcash course would be somewhat shorter than the extensive Bitcoin course, and also that we could redevelop parts of the previous course to speed up deployment. (So, it’s a big technical writing task, but not quite as big as the original.)
The catch is that we’re not sure of the best CLI to use for this, since zcashd and zecwallet are both deprecated and zallet, which we presume will have a CLI, is immature. The alternative is to instead teach through a programming language, which we do in some later parts of Learning Bitcoin, but that loses a lot of the immediacy, so it’d be a second choice only. We’re open to suggestions on the best CLI to use as the foundation of this course if there’s interest!
- GORDIAN SEED TOOL UPGRADE.
- Goal: Provide developers with a reference app & users with a seed vault
- Requirements: none
Gordian Seed Tool is an iOS reference app that allows for the generation, storage, and usage of seeds. It also demonstrates how seeds and keys work with Blockchain Commons specs such as Envelope, SSKR and OIB. It currently offers direct integration with Bitcoin, Ethereum, and Tezos.
We would expand Gordian Seed Tool to also support Zcash. This would include the generation of various Zcash keys and addresses, for easy use with Zcash. If the PCZT spec is sufficiently advanced, we could also use it to sign PCZTs, as we do with PSBTs for Bitcoin. We’d also need to offer best methods or integration for transmitting seeds or keys to the top wallets.
Finally, this would include a minimal demo of OIBs, which would be revamped to support Zcash, likely through specific icons for transparent and shielded addresses.
The main goal here would be to demonstrate/reference for developers, but this is also a practical tool for advanced users, as they can generate seeds, transmit them (or maybe just transmit keys or even watch-only keys) to wallets, and even back up their seeds using SSKR, which is built into GST as another reference. In other words: advanced users can use it as a powerful resilience application to protect their assets.