The members of the Ethereum R&D team and the ZCASH company collaborate on a research project relating to the combination of programmability and confidentiality in block chains. This joint message is being posted simultaneously on the ZCASH blogAnd is co-written by Ariel Gabizon (ZCASH) and Christian Reitwiessner (Ethereum).
Ethereum’s intelligent flexible intelligent contract interface allows a wide variety of applications, many of which have probably not yet been designed. The possibilities increase considerably when adding the confidentiality capacity. Imagine, for example, an election or an auction carried out on the blockchain via an intelligent contract such as the results can be verified by a blockchain observer, but the votes or individual offers are not revealed. Another possible scenario can involve a selective disclosure where users would have the possibility of proving that they are in a certain city without disclosing their exact location. The key to adding such capacities to Ethereum is succinct zero succinct non-interactive arguments (ZK-Snarks)-precisely the underlying cryptographic engine in ZCASH.
One of the objectives of the company ZCASH, appointed by code Project alchemyIt is to allow a direct decentralized exchange between Ethereum and ZCASH. The connection of these two blocks and technologies, one focusing on programmability and the other on privacy, is a natural way to facilitate the development of applications requiring both.
As part of the technical collaboration of ZCASH / Ethereum, Ariel Gabizon de ZCASH went to Christian Reitwiessner of Hub Ethereum in Berlin a few weeks ago. The highest point of the visit is a proof of implementation of a concept of a ZK-Snark verifier written in solidity, based on pre-compiled Ethereum contracts implemented for the Customer Ethereum C ++. This complete work Baby Zoe Where a precompiled contract ZK-SNARK was written for parity (the customer of Rouille Ethereum). The updates that we made involved adding tiny cryptographic primitives (multiplication, addition and matching of the elliptical curve) and implementing the rest in solidity, which all allows greater flexibility and allows to use a variety of ZK-Snark constructions without requiring a hard fork. Details will be shared because they will be available later. We tested the new code by successfully checking a real ZCASH transaction preserving confidentiality on a test test of the Ethereum blockchain.
The verification has only taken 42 milliseconds, which shows that such precompiled contracts can be added, and gas costs to use them can be made to be quite affordable.
What can be done with such a system
The ZCASH system can be reused on Ethereum to create armored personalized tokens. These tokens already allow many applications such as the vote (see below) or simple blind auctions where participants make offers without the knowledge of the amounts that offer the others.
If you want to try to compile concept proof, you can use the following commands. If you need help, see
git clone cd libsnarksudo PREFIX=/usr/local make NO_PROCPS=1 NO_GTEST=1 NO_DOCS=1 \ CURVE=ALT_BN128 \FEATUREFLAGS="-DBINARY_OUTPUT=1 -DMONTGOMERY_OUTPUT=1 \ -DNO_PT_COMPRESSION=1" \lib installcd ..git clone --recursive -b snarkcd cpp-ethereum./scripts/install_deps.sh && cmake . -DEVMJIT=0 -DETHASHCL=0 && make ethcd ..git clone --recursive -b snarkscd solidity./scripts/install_deps.sh && cmake . && make soltestcd .../cpp-ethereum/eth/eth --test -d /tmp/test# And on a second terminal:./solidity/test/soltest -t "*/snark" -- --ipcpath /tmp/test/geth.ipc --show-messages
We have also discussed various aspects of the integration of ZK-Snarks in the Ethereum blockchain, on which we are lying around now.
Decide which precompiled contracts to define
Remember that a Snark is short proof of certain properties, and what is necessary to add the confidentiality features to the Ethereum blockchain, these are customers who have the possibility of verifying such proof.
In all recent constructions, the verification procedure consisted only in operations on elliptical curves. More specifically, the verifier requires a scalar multiplication and an addition on an elliptical curve group, and would also require a heavier operation called bilinear pairing.
As mentioned hereThe implementation of these operations directly in the EVM is too expensive. Thus, we would like to implement pre-compiled contracts that carry out these operations. Now the question debated is: what level of generality should these pre-compound contracts aim for.
The safety level of the Snark corresponds to the parameters of the curve. Basically, the greater the order of curve, the greater something is called the degree of incorporation, and the more the snark is secured according to this curve. On the other hand, the more these quantities are large, of course, the more expensive the operations on the corresponding curve. Thus, a contract designer using Snarks may wish to choose these parameters according to their own compromise of efficiency / desired security. This compromise is one of the reasons for the implementation of a contract pre-compounded with a high level of generality, where the contract designer can choose from a large family of curves. We have indeed started by targeting a high level of generality, where the description of the curve is given within the framework of the entry of the contract. In such a case, an intelligent contract would be able to add the addition in any group of elliptical curve.
A complication with this approach consists in awarding the cost of gas to the operation. You must assess, simply from the description of the curve, and without access to a specific implementation, how much a group operation on this curve would cost the worst case. A slightly less general approach is to allow all the curves of a given family. We have noticed that when we work with the Barto-Naehrig curves (BN), we can roughly assess the cost of the twinning operation, given the curve parameters, because all these curves take care of a specific type of optimal ATE pairing. Here is a sketch The way such a precompiled would work and how the cost of gas is calculated.
We have learned a lot from this debate, but ultimately, we decided to “remain simple” for this proof of concept: we have chosen to implement contracts for the specific curve currently used by ZCASH. We did it using packaging of the corresponding functions in the Libsnark Library, which is also used by ZCASH.
Note that we could simply have used a wrapper for the entire Snark check function currently used by ZCASH, as was done in the Baby Zoe project mentioned above. However, the advantage of explicitly defining elliptical curve operations makes it possible to use a wide variety of Snark constructions which, once again, all have a verifier operating by a combination of the three elliptical curve operations mentioned above.
Reuse the ZCASH configuration for new anonymous tokens and other applications
As you may have understood, the use of snarks requires a Complex configuration phase in which the so-called public parameters of the system are built. The fact that these public parameters must be generated securely each time we want to use a snark for a particular circuit, considerably hinders the conviviality of the snarks. Simplifying this configuration phase is an important objective that we have thought about, but we have not been successful so far.
The good news is that someone wishing to issue a token supporting transactions preserving confidentiality can simply reuse public parameters that have already been safely generated by ZCASH. It can be reused because the circuit used to verify transactions preserving confidentiality is not intrinsically linked to a single currency or blockchain. On the contrary, one of its explicit entries is the root of a Merkle tree which contains all the valid notes of the currency. Thus, this entry can be modified according to the currency with which we want to work. In addition, if it is easy to start a new anonymous token. You can already perform many tasks that do not look like tokens at first glance. For example, suppose we want to make an anonymous election to choose a favorite option between two. We can issue an anonymous custom token for the vote and send a piece to each voting part. Since there is no “look”, it will not be possible to generate tokens in another way. Now, each party sends its room to one of the two addresses according to their vote. The address with a larger final balance corresponds to the electoral result.
Other applications
A system not based on tons which is quite simple to build and allows a “selective disclosure” follows. You can, for example, publish a encrypted message at regular intervals, containing your physical location with blockchain (perhaps with the signatures of others to avoid usurpation). If you use a different key for each message, you cannot reveal your location only for a while by publishing the key. However, with ZK-Snarks, you can also prove that you were in a certain area without revealing exactly where you were. Inside the ZK-Snark, you decipher your location and check that it is inside the area. Due to the Zero-Knowledge property, everyone can check this check, but no one can recover your real location.
The work to come
The realization of the features mentioned – Create anonymous tokens and check the ZCASH transactions on the Ethereum blockchain, will require the implementation of other elements used by ZCASH in Solidity.
For the first features, we must have an implementation of tasks carried out by nodes on the ZCASH network such as the update of the Note engagement tree.
For the second feature, we need an implementation of the equihash work evidence used by ZCASH in Solidity. Otherwise, transactions can be verified as valid in themselves, but we do not know if the transaction has been really integrated into the ZCASH blockchain.
Fortunately, such an implementation was writing; However, its effectiveness must be improved to be used in practical applications.
Acknowledgement: We thank Sean Bowe for his technical assistance. We also thank Sean and Vitalik Buterin for the useful comments and Ming Chan for the edition.
