Members of the Ethereum research & development team and the Zcash Company are joining forces on a research initiative that tackles the integration of programmability and confidentiality within blockchains. This collaborative article is being simultaneously published on the Zcash blog, co-authored by Ariel Gabizon (Zcash) and Christian Reitwiessner (Ethereum).
Ethereum’s adaptable smart contract interface permits a wide range of applications, many of which may not have been imagined yet. The potential increases significantly with the addition of privacy features. For instance, envision an election or auction executed on the blockchain through a smart contract, so that the outcomes can be confirmed by any blockchain observer, yet the individual votes or bids remain concealed. Another potential scenario could include selective sharing, allowing users to demonstrate they are in a particular city without revealing their precise whereabouts. The essential component for incorporating such functionalities into Ethereum is zero-knowledge succinct non-interactive arguments of knowledge (zk-SNARKs) — essentially the cryptographic framework underpinning Zcash.
One of Zcash Company’s objectives, known as Project Alchemy, is to facilitate a direct decentralized interchange between Ethereum and Zcash. Bridging these two blockchains and their technologies—one concentrating on programmability and the other on confidentiality—naturally promotes the growth of applications that require both.
As a component of the Zcash/Ethereum technical collaboration, Ariel Gabizon from Zcash visited Christian Reitwiessner at the Ethereum hub in Berlin a few weeks ago. A significant aspect of the visit was a proof-of-concept demonstration of a zk-SNARK verifier developed in Solidity, based on pre-compiled Ethereum contracts designed for the Ethereum C++ client. This effort complements Baby ZoE, where a zk-SNARK precompiled contract was created for Parity (the Ethereum Rust client). The modifications we’ve implemented involved incorporating small cryptographic primitives (elliptic curve multiplication, addition, and pairing) while constructing the remainder in Solidity, all of which provides enhanced flexibility and supports various zk-SNARK configurations without necessitating a hard fork. Additional details will be disseminated as they become available. We verified the new code by successfully confirming a genuine privacy-preserving Zcash transaction on a testnet of the Ethereum blockchain.
The verification process took just 42 milliseconds, indicating that such precompiled contracts can be integrated, and the gas costs for utilizing them can be kept relatively low.
What can be accomplished with such a system
The Zcash framework can be repurposed on Ethereum to develop shielded custom tokens. These tokens already facilitate numerous applications, such as voting, (see below), or simple blind auctions where participants submit bids without awareness of the amounts offered by others.
If you are interested in attempting to compile the proof of concept, you can utilize the following commands. If assistance is required, refer to https://gitter.im/ethereum/privacy-tech
git clone https://github.com/scipr-lab/libsnark.git cd libsnarksudo PREFIX=/usr/local make NO_PROCPS=1 NO_GTEST=1 NO_DOCS=1 CURVE=ALT_BN128```htmlFEATUREFLAGS="-DBINARY_OUTPUT=1 -DMONTGOMERY_OUTPUT=1 -DNO_PT_COMPRESSION=1"lib installcd ..git clone --recursive -b snark https://github.com/ethereum/cpp-ethereum.gitcd cpp-ethereum./scripts/install_deps.sh && cmake . -DEVMJIT=0 -DETHASHCL=0 && make ethcd ..git clone --recursive -b snarks https://github.com/ethereum/solidity.gitcd solidity./scripts/install_deps.sh && cmake . && make soltestcd .../cpp-ethereum/eth/eth --test -d /tmp/test# And on another terminal:./solidity/test/soltest -t "*/snark" -- --ipcpath /tmp/test/geth.ipc --show-messages
We also explored numerous facets of incorporating zk-SNARKs into the Ethereum blockchain, on which we will now elaborate.
Determining which pre-compiled contracts to establish
Remember that a SNARK is a concise demonstration of a certain property, and what is required to introduce the privacy features to the Ethereum blockchain are clients capable of validating such a proof.
In all recent architectures, the verification process solely comprised operations on elliptic curves. In particular, the verifier needs scalar multiplication and addition in an elliptic curve group, and a more intensive operation known as a bilinear pairing.
As previously indicated here, executing these operations directly within the EVM is excessively expensive. Hence, we would prefer to create pre-compiled contracts that can perform these actions. Now, the question under debate is: what degree of generality should these pre-compiled contracts pursue.
The security level of the SNARK corresponds to the curve’s parameters. Generally, the greater the curve order and the embedding degree, the more secure the SNARK associated with this curve becomes. Conversely, the larger these values are, the more expensive the associated operations on the corresponding curve naturally become. Therefore, a contract designer utilizing SNARKs may opt to select these parameters based on their own preferred efficiency/security balance. This compromise is one motive for developing a pre-compiled contract with a high level of generality, wherein the contract designer can select from a wide range of curves. We indeed commenced with the goal of achieving a high degree of generality, where the curve’s description is included as part of the contract input. In such
“`a scenario, a smart contract could execute addition within any elliptic curve group.
One challenge with this strategy is determining the gas cost associated with the operation. You must evaluate, based solely on the description of the curve and without access to a specific implementation, the potential extent of the expense for a group operation on that curve in the worst-case scenario. A somewhat less broad approach is to permit all curves from a certain family. It was observed that while engaging with the Barreto-Naehrig (BN) family of curves, one can approximately estimate the cost of the pairing operation based on the curve parameters, as all such curves facilitate a specific form of optimal Ate pairing. Here’s a overview of how a precompile might function and how the gas cost would be calculated.
We gained valuable insights from this discussion, but in the end, opted to “keep it straightforward” for this proof of concept: we decided to implement contracts for the particular curve currently utilized by Zcash. This was achieved by employing wrappers for the corresponding functions in the libsnark library, which is also utilized by Zcash.
It’s worth noting that we could have simply utilized a wrapper for the complete SNARK verification function currently employed by Zcash, similar to what was done in the previously mentioned Baby ZoE project. Nevertheless, the benefit of clearly defining elliptic curve operations is that it enables the use of various SNARK constructions which, once again, all have a verifier operating through some combination of the three previously referenced elliptic curve operations.
Reusing the Zcash framework for new anonymous tokens and additional applications
As you might be aware, utilizing SNARKs necessitates a complex setup phase during which the system’s so-called public parameters are generated. The requirement that these public parameters must be created securely each time we intend to use a SNARK for a specific circuit considerably complicates the usability of SNARKs. Simplifying this setup phase is an essential objective we have contemplated, but have yet to achieve any success with it so far.
The positive aspect is that an entity looking to issue a token that supports privacy-enhancing transactions can conveniently reuse the public parameters that have already been securely generated by Zcash. This reuse is possible because the circuit utilized to validate privacy-preserving transactions is not inherently connected to any single currency or blockchain. Rather, one of its specific inputs is the root of a Merkle tree that contains all the valid notes for the currency. Therefore, this input can be adjusted according to the currency one wishes to utilize. Furthermore, it is relatively simple to initiate a new anonymous token. You can already carry out many functions that may not initially appear to be tokens. For instance, let’s assume we wish to conduct an anonymous election to select a preferred choice between two options. We can create a custom anonymous token for the voting process and distribute one coin to each voting participant. Since there is no “mining,” it will not be feasible to generate tokens through any alternative means. Now, each participant sends their coin to one of the two addresses according to their choice. The address with a greater final balance reflects the election outcome.
Additional applications
An uncomplicated non-token-based system that allows for “selective disclosure” can be constructed. For example, you might periodically post an encrypted message that includes your physical location on the blockchain (potentially with signatures from other individuals to deter spoofing). By utilizing a distinct key for each message, you can disclose your location only at a designated time by releasing the key. However, with zk-SNARKs, you can also demonstrate that you were in a particular area without disclosing your precise whereabouts. Within the zk-SNARK, you decrypt your location and verify that it lies within the designated region. Due to the zero-knowledge attribute, everyone can confirm the verification, but no one will have the ability to uncover your actual location.
The forthcoming tasks
Achieving the functionalities described – generating anonymous tokens and verifying Zcash transactions on the Ethereum blockchain will necessitate the implementation of other components utilized by Zcash in Solidity.
For the initial functionality, we need to implement tasks carried out by nodes on the Zcash network such as updating the note commitment tree.
For the secondary functionality, it is essential to implement the equihash proof of work algorithm utilized by Zcash in Solidity. If this is not accomplished, transactions can be validated as valid independently, but we will not verify if the transaction was indeed integrated into the Zcash blockchain.
Fortunately, such an implementation has been developed; however, its efficiency requires enhancement to be applicable in practical scenarios.
Acknowledgments: We express our gratitude to Sean Bowe for his technical support. We also appreciate Sean and Vitalik Buterin for their valuable feedback, and Ming Chan for his editorial contributions.
