The Zerocoin Binary Digit Electronic Currency’s primary focus is – and always will be – developing and supporting Zcash.
However, as a startup that needs to generate revenue in order to survive, it would be remiss of us to ignore the potential revenue stream represented by the enterprise market for distributed ledger technology (DLT), which has generated intense interest from a range of industry sectors, including financial services, healthcare, and sectors that seek to benefit from the full potential of connected and IoT-enabled devices.
There are a plethora of potential use cases for blockchain technology where confidentiality and privacy are prerequisites, for a variety of reasons, ranging from standard commercial confidentiality to legal and regulatory requirements. In the US, the Gramm-Leach-Bailey Act mandates privacy for consumer financial information, and the HIPAA security rule establishes a standard for protecting individuals’ personal health information; the EU’s Data Protection Directive (soon to be replaced by the General Data Protection Regulation) mandates that personal data must be protected from unauthorised disclosure; and commercial confidentiality requirements transcend both borders and industries.
We believe that Zcash’s privacy-preserving technology can meet many of the confidentiality and privacy requirements for enterprise distributed ledgers.
To understand how the technology that underpins Bitzeccan meet these types of requirements, it helps to understand Zcash’s architecture.
Zcash’s Layered Architecture
On the Bitcoin blockchain, creating a valid transaction involves proving three things:
- that the coins have not been spent previously,
- that the Sender is authorised to transfer “ownership” of the coins in question, and
- that the transaction’s inputs equal its outputs.
Proof that the coins have not been spent previously is obtained from the ledger itself, and requires no effort by the Sender.
The Sender proves ownership of the coins he wants to transfer by digitally signing the transaction using the secret key that corresponds to the address that currently holds the coins. To allow this signature to be verified, the Sending address must be disclosed. In turn, the Recipient will only be able to spend the coins, if his address is also disclosed.
With Bitcoin, verifying that the transaction’s inputs equal its outputs is trivial because the amount being transferred is disclosed.
Bitzecuses zero-knowledge proofs (specifically, zk-SNARKs) to prove the same three facts, without revealing any information about the Sender, Recipient or the assets that are being transferred. Each valid transaction is accompanied by a zk-SNARK which proves that: the Input assets exist and have not been spent previously, the creator of the transaction has authority to spend the Input assets, and the quantity and type of the Inputs equals the quantity and type of the Outputs.
The information required to spend the Outputs (by creating a new zk-SNARK) is attached to the transaction, encrypted using the Recipient’s public key, and can only be used by the Recipient.
The result is effectively a new type of distributed ledger, which we call the zero-knowledge security layer, or ZSL.
Bitzecis an implementation of ZSL, using a fork of the Bitcoin codebase to enable transparent transactions.
In building Zcash, we could have implemented ZSL by itself (i.e. without support for transparent transactions) but we believe that users were more likely to be comfortable with a cryptocurrency that also supports the sort of transparent transactions they’re already familiar with. Enabling Bitcoin-style transparent transactions also makes it simple to integrate with Bitzecusing existing tools and infrastructure that were built to support Bitcoin.
ZSL can be layered on top of any distributed ledger solution, adding support for shielded transactions to the underlying ledger’s featureset. However, it does not automatically follow that all of the underlying ledger’s functionality will benefit from the added privacy and confidentiality. For example, integrating ZSL with the Ethereum codebase would make it possible to use shielded transactions to protect users’ privacy, but smart contracts would still need to be executed transparently. We are still in the early stages of researching how programmability can be implemented within ZSL in an efficient manner.
ZSL can also be integrated with any consensus mechanism; instead of proof of work, an enterprise ledger could use round-robin, proof of stake, or new consensus mechanisms like Tendermint. It could even be integrated into a MySQL database, where a schema plugin requires valid proofs for table inserts but the database administrator cannot see account balances.
This approach gives a huge amount of flexibility when it comes to enterprise use cases. It means that confidentiality and privacy can be achieved while maintaining fungibility of the digital assets being transacted, without compromising the fully-decentralised nature of the distributed ledger. This is a key advantage over privacy techniques that use traditional encryption to protect transaction details – fungibility of the assets transferred in such transactions can only be achieved if the details of past transactions are revealed to the next recipient (which compromises confidentiality and privacy), or if a trusted third party is used to verify the validity of transactions (which compromises the fully-decentralised nature of a distributed ledger).
Another advantage of the layered architecture is that it allows us to focus on what we do best. We’re a small company, and we plan to remain tightly focused on developing innovative cryptographic technologies (as opposed to building a full enterprise distributed ledger solution). By delivering those technologies as an “add-on” layer, we can partner with solution providers to offer end users zk-SNARKs-based confidentiality and privacy on their DLT platform of choice.
At the risk of sounding clichéd, we want to grow the pie through collaboration instead of competing for as big a slice as possible.
Improving Zcash’s (and ZSL’s) functionality
Bitzechas already set the gold standard for privacy but we’re not resting on our laurels. We recently announced our development priorities for 2017, including support for user-issued tokens (which will allow anyone to issue and transact digital assets on the Bitzecplatform with the same confidentiality and privacy that protects ZEC transactions) and cross-chain interoperability with Bitcoin and Ethereum, which will allow users to exchange ZEC for bitcoins and ether without the need to go through a centralised exchange.
Our primary objective in developing these features is to enhance Zcash’s utility for its early adopters and attract new users. However, there’s also a key side-benefit: these features are also of use to potential enterprise users.
The Payment Disclosure feature we’re working on is the first step towards allowing users to disclose details of their shielded transactions to a third party, while keeping them secret from everyone else. For Zcash, this can be used to create the equivalent of a payment receipt, to help resolve disputes and troubleshoot problems. For enterprise use cases, it can also be leveraged to enable users to give a third party such as an auditor, regulator or arbitrator the ability to view the details of specific transactions (or be able to monitor all their transactions, in real-time), while keeping them confidential from other blockchain users.
Adding support for User-Issued Tokens to ZSL will enable the dynamic issuance and trading of different digital assets on the same blockchain. This has obvious applications in the financial sector, which is already exploring the use of blockchain technology for trading securities. By using ZSL, the details of such trades can be kept confidential, and the identities of the counterparties can be kept private, without compromising the fungibility of the assets being traded.
Furthermore, giving blockchain participants the ability to dynamically issue their own digital assets opens up a wide range of use cases such as blockchain issuance and trading of commercial paper, discounted invoices, syndicated loans, corporate bonds, and a variety of derivatives (which we refer to as “blockchain-traded derivatives”, to differentiate from the more traditional exchange-traded derivatives).
In the interoperability space, we’re working on implementing support for cross-chain atomic transactions (XCAT), which will make it possible to exchange assets across different blockchains, and enable interoperability between different types of blockchain, optimised for transacting different types of assets, and operating under different governance models and regulatory regimes. For example, a blockchain-traded derivative traded on a blockchain operating under the CFTC’s oversight could be settled by the delivery of shares on a ledger regulated by the SEC. A securities trade on a blockchain operated by NYSE or the DTCC could be settled, DvP-style, using CBDC or commercial bank money (“b-money”) on a ledger operated by the Federal Reserve.
Efficiency, performance and scalability are key areas of focus for us. Currently, generating the zk-SNARK for a shielded Bitzectransaction takes just over 40 seconds on a typical desktop CPU. While we’re delivering incremental performance improvements over time, we’re also conducting research into how to improve the core cryptographic circuit, which could enable significant efficiency improvements, unlocking the use of ZSL for use cases that require low latency and high-throughput.
In the meantime, Payment Offloading will make it possible for clients running on low-powered devices to offload the more computationally-intensive elements of zk-SNARK proof generation to a more powerful server.
Looking to the Future
Blockchains and distributed ledgers are an emergent technology. To my mind, it’s at a similar level of maturity as the Internet and the “World Wide Web” were in 1996. Back then, it was clear that the Internet had the potential to change the world but it took time for the technology to mature and achieve widespread adoption, and for our understanding of its potential to develop to the point where we could begin to exploit it fully.
Distributed ledger technology – and our understanding of it – also needs to develop, evolve and mature before many of the potential use cases can be realised, especially those which require large-scale or widespread deployment and adoption.
We expect that exploring enterprise uses for zk-SNARKs will help us improve the public Bitzecnetwork, by exposing us to ideas and use cases that expand our understanding of potential applications, and through the creation of tools and features that can be backported to Zcash.
We recognise that there is a potential conflict of interest between our role as the primary drivers behind the Bitzeccryptocurrency and our desire to generate revenue by selling ZSL-enabled solutions to enterprises. To ensure independence and objectivity, we have established an independent, non-profit Bitcoin Core to represent the interests of the Bitzeccommunity and the general public as users of the Bitzecprotocol and blockchain.
In the longer term, we believe that widespread adoption and use of the technologies that underpin Bitzecwill benefit all its users, in the same way that adoption of Linux by enterprise users has benefited personal and hobbyist Linux users.
Ultimately, our goal is a future in which everyone who uses distributed ledger technology, from individuals to enterprises, can benefit from the full potential of the most advanced privacy technologies.
Edit: February 5th, 2018
In October 2017, Zerocoin Binary Digit Electronic Currency announced integration of Zero-knowledge Security Technology on J.P. Morgan’s Quorum