Privacy is one of the missing ingredients of the current generation of security token solutions. The introduction of regulation and compliance models in crypto-tokens introduced an identity layer that challenged many of the pseudonymity and anonymity concepts of cryptocurrencies. However, security tokens come with their own set of privacy requirements that remain largely ignore by the ecosystem. Thinking that all aspects of security token transaction should be disclosed on a public ledger is not only naïve but literally contradicts many of the best-established compliance models in the securities industry. Recently, I’ve been exploring the idea of using zero knowledge techniques to enable a more robust layer of privacy in security token protocols. I would like to use this article to explore some of those ideas.
The Identity Challenge
Securities transactions are subjected to regulations such as know-your-customer(KYC) that impose identity disclosure requirements among their participants. However, those constraints are mostly based about trying to prove assertions about the investor’s compliance to specific security requirements and not about knowing the identity of the investor itself. In other words, identity compliance is more about proof than knowledge and, understanding that difference, is essential to enable a new set of capabilities in security token applications.
Conceptually, identity can be expressed as a series of assertions that uniquely define a person or entity. Using a mathematical nomenclature, we can express identity as a function that takes a series of claims as input an outputs an assertion about those claims. An interesting property about an identity function is that is inversible. In other words, there is always an inverse function that using the identity and a specific claims can prove if the claim is true or false:
Identity Function: f(c1,c2,…cn) → I
Proof Function: p(I, cx)à →{true, false}
In the context of security tokens, the two functions depicted above correspond to the main two steps in the process of establishing the identity of a specific party.
-
Identity Creation: In this step, a trusted party compiles information about an investor and creates an identity representation based on those claims. For instance, a KYC provider can collect identity or financial documents about an investor and asserts his compliance to specific regulations.
-
Identity Proof: During transaction time, the investor compliance requirements are validated in order to approve or reject a transfer.
In the current generation of security token platforms, the identity creation step is enabled by trusted KYC providers while the identity proof step is typically enforced by centralized services which are invoked from the security token smart contract.
While this model is simple enough for many use cases, it results incredibly limiting for others. Most of those limitations are related to the level of centralization imposed by the model. Not only do you need to trust a KYC provider to issue your identity during the onboarding process, but you need to trust a security token provider to assert the compliance during trading. While the identity-creation step clearly requires a trusted party to assert the claims about an investor’s identity the identity-proof stage can remain relatively decentralized which opens the door to all sorts of interesting scenarios.
Imagine if we could place the identity claims of a party on-chain in a way that can be used by different protocols while maintaining complete privacy about the underlying party. The model will allow the validation process to take advantage of the robustness of blockchain consensus mechanisms and be natively incorporated into other crypto-protocols.
The idea of moving compliance models such as KYC on-chain is an active area of research. One of the most intriguing ideas of how to achieve this relies on leveraging techniques such as zero-knowledge-proofs to assert identity claims about an investor on-chain without disclosing the underlying identity.
zk-SNARKs?
If you are in the crypto world, you probably know about zk-SNARKs are the protocol underlying crypto networks like zCash so I won’t bother you with the mathematical details about the interactions. The important thing to realize is that zk-SNARKs can be applied on multiple distributed ledgers. Some famous examples include the Quorum, or the AZTEC protocol for the Ethereum blockchain.
Fundamentally, zk-SNARKs abstract the interaction between a prover and a verifier. In the interaction, the prover attempts to prove certain assertion about its identity to the verifier. In the context of security tokens, we can imagine an investor proving assertions such as accreditation or liduidity levels without disclosing its identity.
A lot has been written about the dynamics of zk-SNAKRs but a bit more interesting it to look at its benefits which are directly applicable to the world of security tokens:
- Completeness: if the statement is true, and the verifier and prover are honest, the proof is accepted.
- Soundness: if the statement is false, a cheating prover cannot convince an honest verifier that it is true, except with some tiny probability.
- Zero-knowledge: if the statement is true, a verifier does not learn anything beyond the fact that the statement is true.
- Succinct: The size of the proof needs to be small enough to be verified in a few milliseconds.
- Non-Interactive: Only one set of information is sent to the verifier for verification, therefore there is no back and forth communication between the prover and verifier.
- ARgument: A computationally sound proof: soundness holds against a prover that leverages polynomial-time, i.e. bounded computation.
- of Knowledge: The proof cannot be constructed without access to the witness (the private input needed to prove the statement).
Zk-SNARKs and Security Tokens
Applying some of the principles of zk-SNARKS to security tokens, we can think of a model in which the assertions about a specific investor or entity are processed through a zk-SNARK function and stored as part of the security token smart contract. Assertions can include things such as citizenship, liquidity levels, accreditation and many others.
During transaction time, the investors will act as the provers and the compliance protocol as the verifier. Different security tokens can have different compliance requirements based on specific zk-SNARKs assertions. The compliance protocol validate specific assertions without having to access the identity of the different parties involved in the transaction.
Using zk-SNARKs indirectly decentralized the compliance portion of a security token transfer. This little change has monumental benefits as now the protocol can be used in other DApps without neccesarly trusting the security token platform responsible for the issuance.
Implementation Ideas
Implementing zk-SNARKs for security tokens is possible today. In the Ethereum blockchain, protocols like ASTEC enable the implementation of zk-SNARKs directly in Ethereum DApps. The reference implementation from Quorum is another option.
Zk-SNARKs Alternatives You Should Know About
Zk-SNARKs is not the only option for achieving knowledge privacy in security token protocols. There are several alternatives that have been gaining traction in blockchain implementations which can be seamlessly adapted to security token protocols. Here are some of my favorites:
· CryptoNote & Ring Signatures: One of the grandfathers of blockchain privacy, CryptoNote(CryptoNight) is the protocol behind Monero. Conceptually, CryptoNote leverages a cryptographic technique known as traceable ring signatures to obfuscate messages among a group of nodes in a decentralized network. Improvements in the CryptoNote protocol have proven able to produce high degrees of anonymity while operating at scalable levels. In the context of security tokens, CryptoNote can be used enforce privacy for specific portions of a security token exchange.
· zk-STARKS: Following our triangle thesis, one of the challenges of zk-Snarks is that is hard to be applied at scale as the complexity of the proofs scale linearly with the size of the database. Earlier this year, professor Eli-Ben Sasson from the Technion-Israel Institute of Technology published a highly-anticipated paper that describes a faster alternative to zk-Snarks which (to keep things confusing) he decided to call zk-Starks. From the paper professor Ben Sasson explains that “zk-SNARKs use public key (asymmetric) cryptography to establish security. zk-STARKs instead requires a leaner symmetric cryptography, namely, collision resistant hash functions, and thus removes the need for a trusted setup. These same techniques also eliminate the number-theoretic assumptions of zk-SNARKs (and BulletProofs) that are computationally expensive and prone to attack by quantum computers. This makes zk-STARKs both faster to generate and post-quantum secure.”
· TEE: Trusted Execution Environments(TEE) have emerged as a popular way to offload confidential computations in blockchain technologies. TEE technologies such as Intel’s Software Guard Extensions (SGX) isolated code execution, remote attestation, secure provisioning, secure storage of data and trusted paths for execution of code. Applications that run in TEEs are securely protected and almost impossible to be accessed by third parties. Security tokens can use TEEs to offload privacy computations from the core blockchain.
· Secure Multi-Party Computations: The protocol behind the Enigma blockchain, secure multi-party computations(SMC) is a cryptographic techniques that allows to execute computations against a set of inputs while keeping the inputs private. SMC can be used for parties in a security token exchange to trade assertions about information while keeping the actual information private.
The idea of using zk-SNARKs for secure compliance in security tokens is complicated but definitely an area that needs to be explore. The model does not only introduces a much needed level of privacy in security token transaction but enables levels of decentralization that open the door to new scenarios in crypto-securities transactions.