Update on Zcash integration into Ethereum (ZoE)
Members of the Ethereum R&D team and Zcash Company are collaborating on research projects that address the combination of programmability and privacy in blockchains. This joint post will be posted simultaneously on . Zcash BlogCo-authored by Ariel Gabizon (Zcash) and Christian Reitwiessner (Ethereum).
Ethereum’s flexible smart contract interface enables a variety of applications perhaps not yet conceived. Adding privacy features increases the possibilities considerably. For example, imagine an election or auction conducted on a blockchain through smart contracts. Results can be verified by any observer on the blockchain, but individual votes or bids are not public. Another possible scenario could include selective disclosure, where users can prove they are in a specific city without revealing their exact location. The key to adding these capabilities to Ethereum is zero-knowledge compact, non-interactive knowledge arguments (zk-SNARKs), the crypto engine that underlies Zcash.
Codenamed Zcash One of the company’s goals project alchemy, which enables direct decentralized exchange between Ethereum and Zcash. Bridging two blockchains and technologies that focus on programmability and privacy is a natural way to facilitate the development of applications that require both.
As part of the Zcash/Ethereum technical collaboration, Zcash’s Ariel Gabizon visited Christian Reitwiessner at the Ethereum hub in Berlin a few weeks ago. The highlight of the visit was a proof-of-concept implementation of the zk-SNARK validator written in Solidity based on pre-compiled Ethereum contracts implemented for the Ethereum C++ client. This work complements this. baby joy Here the zk-SNARK precompiled contract is written for Parity (the Ethereum Rust client). The updates we made included adding small cryptographic primitives (elliptic curve multiplication, addition, and pairing) and implementing the rest in Solidity. All of this increases flexibility and allows the use of a variety of zk-SNARK configurations without the need for a hard fork. . More details will be shared later as they become available. We tested our new code by successfully verifying real privacy Zcash transactions on a testnet on the Ethereum blockchain.
Verification took only 42 milliseconds, which shows that we can add precompiled contracts and make the gas cost of using them significantly cheaper.
What can you do with such a system?
The Zcash system can be reused on Ethereum to create custom, secured tokens. These tokens already allow for many applications, such as voting (see below) or simple blind auctions where participants bid without knowing how much others have bid.
To compile the proof of concept, you can use the following command: If you need help, see: 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 \FEATUREFLAGS="-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 a second terminal:./solidity/test/soltest -t "*/snark" -- --ipcpath /tmp/test/geth.ipc --show-messages
We have also discussed various aspects of integrating zk-SNARK into the Ethereum blockchain and are currently expanding on this.
Determine which precompiled contracts to define
Remember, a SNARK is a brief proof of some property, and all that is needed to add privacy to the Ethereum blockchain is a client with the ability to verify such proofs.
In all recent configurations, the verification procedure consisted only of operations on elliptic curves. In particular, the verifier requires scalar multiplication and addition over groups of elliptic curves, and also requires heavier operations called bilinear pairings.
As said here, it would be too expensive to implement these operations directly on the EVM. So we want to implement a precompiled contract that performs these tasks. The question now being discussed is at what level of generality should precompiled contracts aim?
The security level of SNARK corresponds to the parameters of the curve. Roughly speaking, the larger the curve order and the larger the Embedding Degree, the safer the SNARK based on this curve will be. On the other hand, the larger these quantities, the more expensive the curve will naturally be to work with. Therefore, contract designers using SNARKs may want to choose these parameters based on their desired efficiency/security balance. This trade-off is one of the reasons for implementing precompiled contracts with a high level of generality that allows contract designers to choose from a variety of curves. In practice, we set out to aim for a high level of generality, where a description of the curves is provided as part of the contract input. In this case, the smart contract can perform additions on any group of elliptic curves.
A complication with this approach is allocating gas costs to tasks. Without access to a specific implementation, you need to assess what the cost of a group’s work on that curve would be in the worst case, based solely on the curve description. A somewhat less common approach is to allow all curves from a particular family. When working with the Barreto-Naehrig (BN) family of curves, we see that every curve supports some kind of optimal Ate pair, so we can roughly estimate the cost of working on the pair by considering the curve parameters. here sketch It explains how such precompilation works and how gas costs are calculated.
We learned a lot from this debate, but ultimately decided to “keep it simple” with this proof of concept. We decided to implement a contract for the specific curve currently used by Zcash. We did this using a wrapper for that function. libsnark This library is also used in Zcash.
We could have simply used a wrapper over the full SNARK verification functionality currently used in Zcash, as was done in the Baby ZoE project mentioned above. However, the advantage of explicitly defining elliptic curve operations is that we can use a variety of SNARK configurations, all with validators that operate on a combination of the three previously mentioned elliptic curve operations.
Reuse Zcash settings for new anonymous tokens and other applications
As you may have heard, to use SNARKs Complex setup steps The so-called public parameters of the system are configured. The fact that these public parameters must be generated in a secure manner whenever we want to make significant use of SNARK for a particular circuit hinders the usefulness of SNARK. Simplifying this setup step is an important goal we’ve been thinking about, but we haven’t had any success so far.
The good news is that anyone looking to issue tokens that support privacy-preserving transactions can simply reuse the public parameters already securely created by Zcash. Privacy Preservation Because the circuitry used to verify transactions is not inherently tied to one currency or blockchain, it is reusable. Rather, one of the explicit inputs is the root of the Merkle tree containing all valid notes of the currency. Therefore, this input may change depending on the currency you are working with. Plus if it’s easy to start a new anonymous token. You can already do a lot of things that don’t seem like tokens at first glance. For example, let’s say you want to conduct an anonymous election to choose which of two options you prefer. You can issue anonymous custom tokens for voting and send one coin to each voting party. Since there is no “mining” it is impossible to generate tokens in any other way. Now each party sends its coins to one of two addresses based on votes. The address with the larger final balance corresponds to the election result.
Other applications
This is followed by a tokenless-based system that is very simple to build and allows for “selective disclosure.” For example, you could periodically post an encrypted message containing your physical location to a blockchain (perhaps with someone else’s signature to prevent spoofing). If you use a different key for each message, making your key public allows you to reveal your location only at certain times. However, zk-SNARKs allow you to further prove that you were in a specific area without revealing your exact location. Decode the location within zk-SNARK and check if the location is within the area. Because of its zero-knowledge nature, everyone can see the check, but no one can retrieve its actual location.
What to do next
To achieve the mentioned functionality (creating anonymous tokens and verifying Zcash transactions on the Ethereum blockchain), we need to implement other elements used by Zcash in Solidity.
The first functionality requires implementing tasks performed by nodes in the Zcash network, such as updating the note commit tree.
The second functionality requires Solidity to implement the Equihash proof-of-work algorithm used by Zcash. Otherwise, the transaction itself may be verified as valid, but it is unknown whether the transaction has actually been incorporated into the Zcash blockchain.
Fortunately, such an implementation written; However, to be used in practical applications, efficiency needs to be improved.
approval: Thanks to Sean Bowe for technical assistance. We would also like to thank Sean and Vitalik Buterin for helpful comments and Ming Chan for editing.
