Zcash Elastic Subnet Bridge on Avalanche

[dontpanicburns]

Global greetings:
On behalf of the @ZcashGrants I want to thank you all for your continued engagement in this topic and this informative thread. The ZCG has met with Mr Kit and are in the process of reviewing and discussing the grant proposal.

The ZCG has the following open questions to @mrkit2u

1. Liquidity:
   • Other projects have been funded in the past and saw low adoption (RenZec), How will this project be different from others aside from being a bridge to a different network.
   • How will users be incentivized?
   • Is there urgency in the funding request(ie only so many bridges will exist)?
   • Will the liquidity of the bridge be only from ZCG?
2. Disaster Recovery:
   • Is it accurate to say if Zcash was banned tomorrow the only alternative way to acquire ZEC would be via decentralized bridge (and none currently exist)?
     • How are decentralized bridges managed in the AVAX ecosystem?
   • Would zcash miners need to support this?
3. Mechanics of going from shielded or transparent ZEC to the AVAX-ZEC:
   • How will the bridge work specifically?
   • Will users need two wallets (Avax/ZEC)?
   • Will AVAX-ZEC be supported on any AVAX wallet?
   • Would there be support for hardware wallets on AVAX side?
4. Scope of work:
   • Does part 1 code base completes an integration with testnets only?
     • What percentage of the work does Part 1 cover?
   • How much additional effort will be required to move from test net to Part 2 and 3?

[Milton]

Is it accurate to say if Zcash was banned tomorrow the only alternative way to acquire ZEC would be via decentralized bridge (and none currently exist)?

I was actually wrong about that, there is at least one atomic swap dex that supports zcash.

AtomicDEX — Non-custodial Wallet, Crypto Bridge, and DEX

[mrkit2u]

Hello @ZcashGrants,

Here are some answers to your questions. Please let me know if you would like me to elaborate more on anything or have additional questions.

Kit

1. Liquidity:

• Other projects have been funded in the past and saw low adoption (RenZec), How will this project be different from others aside from being a bridge to a different network.

Regarding user adoption, please look again to the Bitcoin-Avalanche bridge usage data. Adoption was slow to catch on at first and then grew over time. I expect the same to be true of this bridge. However, this bridge would have two additional features that would encourage adoption:

• Support for cross-bridge querying. Users and apps on Avalanche would be able to query Zcash transactions. One can imagine use-cases where Avalanche apps use what happens in shielded Zcash transactions on Zcash to make decisions, without any funds moving across the bridge.

• Support for Layer Zero’s OFT standard which allows transparent access through Layer Zero bridging onwards to many other defi chains and protocols. (Layer Zero cannot support Zcash directly.)

• How will users be incentivized?

This will be addressed in Part 2 which is outside the scope of this proposal. However, one idea would be to provide a token airdrop on bridge first usage, based on data from a snapshot taken earlier.

Bridge validators (wardens) would earn payments for bridging assets and for querying blockchain data.

• Is there urgency in the funding request(ie only so many bridges will exist)?

The primary urgency imo is to integrate Zcash with the greater crypto ecosystem before it becomes a backwater. I think the conventional way Zcashers think about bridging is, “How will community members and I be able to use this bridge with our assets?” but this mindset misses what is more urgent imo, which is, “How will this bridge enable everyone else not yet on Zcash to use Zcash and the state-of-the-art ZKP tech on which it is built?”

Second, the red·dev team is ready to build this now, but if the community is not yet ready to build this bridge, we will shift our focus elsewhere. It’s always challenging to pull together a dev team with the right combination of skills, and I expect that it will become more difficult in the next bull market.

There will be other bridges; there already are other bridges, and it’s a hot, competitive market.

• Will the liquidity of the bridge be only from ZCG?

The design of this bridge does not require liquidity pools. Bridge users’ ZEC is locked in a Zcash wallet, and ZEC.z is then minted on the Avalanche side. Flowing back, ZEC.z is burned, and ZEC is unlocked. Liquidity might be required on defi platforms such as Trader Joe, to make it easy to trade ZEC.z for other assets, but this happens beyond the bridge. Validators will need a token for staking, and some of it may be owned by the Foundation, ZCG, ECC, etc. Deciding this is part of the scope of Part 2.

2. Disaster Recovery:

• Is it accurate to say if Zcash was banned tomorrow the only alternative way to acquire ZEC would be via decentralized bridge (and none currently exist)?

A decentralized bridge provides more robust protection if a country were to ban Zcash, as the validators could be moved to other countries where Zcash is still legal. A decentralized bridge is not dependent on the location of the sponsoring company. etc. No one bridge is a bullet-proof solution though; redundant bridges and asset transfer strategies are key imo.

• How are decentralized bridges managed in the AVAX ecosystem?

The proposed Zcash-Avalanche bridge would be the first of its kind. Subnets are new, and Elastic (permissionless) Subnets are even newer. Each Subnet maintainer is responsible for managing their own Subnet.

• Would zcash miners need to support this?

They would need to include transactions to and from the bridge wallets in their blocks.

3. Mechanics of going from shielded or transparent ZEC to the AVAX-ZEC:

• How will the bridge work specifically?

We now propose only supporting bridge transfers from unshielded ZEC across the bridge. One reason is because once on the AVAX side, it will become unshielded anyway.

• Will users need two wallets (Avax/ZEC)?

No. Though the addressing schemes are different, the same private key can be used to control assets on both sides on the bridge. The same is true for bridged BTC (btc.b).

• Will AVAX-ZEC be supported on any AVAX wallet?

On the Avalanche side, ZEC.z will be an ERC-20 token, and all wallets support these.

• Would there be support for hardware wallets on AVAX side?

Yes. Ledger has good support for Avalanche and for C-Chain ERC-20 tokens.

4. Scope of work:

• Does part 1 code base completes an integration with testnets only?

Yes, just as stated. This is because the deployment decisions in Part 2 are complex and have more stakeholders. We can begin talking about deployment though as we proceed through Part 1.

• What percentage of the work does Part 1 cover?
• How much additional effort will be required to move from test net to Part 2 and 3?

It is a bit hard to say at this point, which is why we did not yet provide estimates past Part 1. Part 2 could go very quickly if everyone agrees on how to deploy the bridge, as the software would be ready to go and tested at the end of Part 1.

[David_Heisenberg]

Unless someone can say why this 100% won’t work, I’d say go for it. Without experimentation connecting Zcash to other islands of activity, I do think we run the risk of remaining too isolated.

I do have a question for Kit, and I apologize if it has been answered before, do you have a long-term vision for this project? I think it is really important for folks asking to do potentially big things in Zcash to be interested in sticking around for a minimum of a few years to cultivate whatever it is they are building.

Thanks

[mrkit2u]

Hi David,

I’m glad you asked re long-term vision because I may have mentioned these things before, but it is good to put them both together in one place.

1. The bridge needs to be self-sustainable, like Zcash is. It will produce a revenue stream based on use, so this seems possible. A Foundation plus a software company seems like a structure that has worked well for many projects including both Avalanche and Zcash, so this seems like a good starting place. I could see red.dev being the software company.

2. The most important thing that the bridge can do for Zcash, imo, is to allow Zcash to provide the ZKP services that businesses need to the Avalanche ecosystem. Anytime two businesses need to interact, they will need ZKP services. 99% of use-cases for ZKPs are related to normal business activities and to citizens who want to legally protect their own privacy, yet this sometimes is not the public’s perception. If Zcash can provide useful business services to other Subnets in the Avalanche ecosystem through this bridge, it can weave itself into the greater cryptocurrency ecosystem, and with increased business use comes increased protection for the Zcash platform. These tools will need to be built.

Kit

[decentralistdan]

@mrkit2u & Zcash Community, I am happy to inform you that the @ZcashGrants Committee has voted to approve this grant proposal at the most recent meeting.

[Milton]

One thing I would like to know is the hardware requirements to run a node for this SGX bridge. I read that SGX has been deprecated for consumer CPUs. Since 11th and 12th gen only Xeon CPUs have SGX. Will older consumer CPUs that had SGX support be able to run the bridge software?

[mrkit2u]

What you say is true about standard workstations not supporting SGX. You need about $2000 USD to buy a server that has SGX in today’s market. We’ll get exact hardware specs out as we move forward. You can also rent hosted servers with SGX from Azure.

BTW, we are very excited and honored to have this opportunity. Thanks to everyone for your questions and comments.

Kit

[dismad]

@mrkit2u

we are very excited and honored to have this opportunity. Thanks to everyone for your questions and comments.

While partial to the cosmos ecosystem (IBC), I’m excited to see this built and am excited to experiment when it’s ready. I have never had a reason to venture into AVAX until now. Thank you and good luck!

[mrkit2u]

Well, I have always admired the Cosmos architecture and ecosystem–just haven’t ever taken the deep dive. One can just divide one’s time so much! I hope the bridge to Namada on Cosmos also takes shape in the coming months.

[mrkit2u]

I just finished attending the Avalanche Summit in Barcelona, and of course I talked to as many people as I could about the Zcash-Avalanche bridge. Everyone who I talked to from the greater Avalanche community reacted positively. I spoke with not just individuals but also with the leaders of other projects on Avalanche. Some remarked on being further encouraged by reading about the support from the Zcash community for it. Discovering this level of positivity for the project was uplifting.

Feedback from Ava Labs employees was more mixed, from an extremely enthusiastic, “AWESOME!” to a tepid, “Thank you for briefing me on your project’s progress and intent.” The higher I reached in the organization’s structure, the more tepid the response, it seemed. This confused me, as Avalanche is actually quite pro-privacy! Their private Subnets provide complete transaction shielding to their owners while still providing fast access to the rest of Avalanche. The Zcash-Avalanche bridge would provide similar privacy for any person or company that can’t afford the thousands of AVAX required to maintain a Subnet.

So why the negativity? The trouble I think is that many Ava Labs employees come from a Wall Street or Fortune 500 background, and they just aren’t that interested in crypto products that don’t cover use-cases for these constituents. To them, Zcash is seen as just another privacy coin, lumped together with the rest, and its differentiator, ZKPs, is not appreciated. However, if Zcash could provide useful ZKP signaling services to the Avalanche ecosystem, the bridge would then provide useful business-to-business tools that large companies could use and that Ava Labs employees would appreciate.

Though Avalanche is itself permissionless, Ava Labs does exert considerable influence over the ecosystem through marketing and business development. Given the overall community sentiment, their support is not required, but it would be a great thing if their enthusiasm grew for this project. We will continue to discuss it with them, and there’s plenty here for them to like, imo.

I look forward to attending Zcon4 in late July (back to Barcelona!) and having similar discussions with all of you in person.

[David_Heisenberg]

Nice to see your reflections and critical thinking. So far, the views of the Wall Street / Fortune 500 crowd you alluded to may also be reflected in the general market sentiment towards ZEC. Although, that is hard to disentangle from many other contributing factors, such as usability. IMO, there’s a combination of “Who cares?” or “So what?” when talking about Zcash’s value prop to general audiences, and even crypto audiences, as well as “Ok, I’m interested, show me what I can do.” but not being able to do very much. Need to be able to solve both those problems IMO.

[mrkit2u]

Hello. I’d like to give everyone a progress report on our work so far on the Zcash-Avalanche Bridge project. After some preliminaries, we are now one two-week sprint into work. We have spent the time as follows:

• We have created our own mainnet and testnet nodes for both Zcash and Avalanche, all four running on the same server. All are fully operational.
• We have taken a deep dive into understanding how non-EVM subnets are configured on Avalanche, using the TimestampVM in particular as an example.
• We have begun to familiarize ourselves with Ava Lab’s quick-launch tool for subnets, HyperSDK.
• We have discussed security risks and mitigations for implementing an asset bridge using an elastic subnet.
• Regarding marketing, we have brainstormed about how best to leverage our completion of Milestone 1 to bring more attention to the project from the Zcash and Avalanche communities.
• Regarding operations, we have established redundant methods of exchanging ZEC for USD and stablecoins, to maintain stable operations.

Note that the dates in our proposal were based on beginning work on April 4, but because it took four weeks for it to be approved and an additional two weeks to ramp up operations for this project, please add six weeks to the dates for our timeline forecast. We estimate completing Milestone 1 by July 15.

Here is a question for everyone. Once past Milestone 1, we will have created an oracle on Avalanche of Zcash that will allow you to query Zcash transactions from Avalanche. What would be an exciting use-case to illustrate the utility of this? We are thinking about something having to do with selectively decrypting the contents of shielded Zcash transactions. Ideas?

@ZcashGrants

[mrkit2u]

Announcing ZavaX Oracle

To demonstrate our completion of Milestone 1 of the Zcash Elastic Subnet Bridge on Avalanche, red·dev is excited to announce ZavaX Oracle! Along with our first deliverable, we have decided to name our project ZavaX. We like this name because it is short and snappy, it pays homage to both Zcash and Avalanche, and the capital X symbolizes a crossing or bridge.

The Deliverable

Deliverable 1.1: Preliminary PoC that supports querying testnet Zcash transactions from a testnet Avalanche subnet with a CLI, published on Github and with a one-node subnet on the Avalanche testnet.

The ZavaX Oracle exceeds what is required for this deliverable in three ways:

• In addition to providing a command-line interface, we are also providing a simple web-based GUI, to make it easy for more people to try it out.
• Instead of querying transactions on the Zcash testnet, we are querying full blocks of transactions from the Zcash mainnet, as these pertain to Zcash users’ daily lives.
• Instead of using a one-node Avalanche subnet, the ZavaX subnet contains three nodes, allowing for us to test consensus mechanisms, to illustrate the utility of multiple redundant endpoints, and to increase fault-tolerance.

Usage

The website, located at https://zavax-oracle.red.dev, is easy to use. We recommend using Brave or Chrome. Just select one of the three ZavaX subnet nodes to be your endpoint (where you are submitting your request), enter the block height of a block in the Zcash blockchain (between 1 and about 2156229) that contains the transaction that you are interested in viewing, and press Submit to ZavaX. The website will then send the request to the node on the ZavaX subnet that you selected. There are two possibilities of what will happen next.

1. If the Zcash block has previously been added to the ZavaX subnet’s chain, the node will respond with the contents of the block. Below the Response box, you can see what ZavaX block was used.
2. If the block has not yet been added, the node will initiate a request to add the Zcash block you requested to the ZavaX subnet’s chain, and a consensus conversation will take place between the subnet’s nodes. The website will wait a few seconds for the consensus conversation to finish and then will ask for the block again. By this time, the ZavaX nodes should have reached consensus and added your Zcash block to the ZavaX subnet’s chain, so the node will respond with the Zcash block’s contents.

You may be surprised at how quickly this happens. Avalanche consensus is fast. On top of that, only three nodes need to reach consensus which only takes milliseconds. (Avalanche consensus scales logarithmically, so even with thousands of nodes, it will still only take about a second.)

Note 1: The ZavaX Oracle subnet is running on the Avalanche Fuji testnet, and it is performing queries only, so no gas is required.

Note 2: This is proof-of-concept software, and from time to time, it may not function perfectly. We are testing new infrastructure and new code, and we are building on top of brand new features of Avalanche. As you probably know, with software, “brand new” has its downsides. Please report any problems you encounter to us, and we will resolve them as quickly as possible.

For Techies

If you would like to try this out yourself from the command line, you can use the curl command in the Request box. You will need to grab a copy of the SSL cert for this to work and add its path to your curl command (it is available in the GitHub repo).

There is a link on the website to the source code on GitHub. The code, which is based on examples provided by Ava Labs, can also illustrate to other Avalanche subnet builders about how to build a basic non-EVM subnet.

In the next few months, we will be performing stress tests on the ZavaX subnet, for instance monitoring behavior when validators expire or behave in a byzantine manner. We will announce some of these tests here so that you can participate.

* * *

We are happy to have reached this milestone. This seemingly simple project has allowed the red·dev team to familiarize ourselves with most of the important pieces of technology that we will combine to build this bridge—from the resources Ava Labs provides, to the Zcash chain and Zcashd, to our first non-EVM subnet, and so on.

Our next step is to create the specification for the bridge itself. We intend to proceed carefully; we are building a bridge to last. It seems that with each passing week, another bridge fails, so we are wary. However, just as blockchains can stand the test of time, so can bridges with the proper safeguards.

It is also important for the long-term health of the ZavaX technology to establish business partnerships, so please consider this forum post an open solicitation to other businesses to join with us around ZavaX—whether to create an oracle subnet on Avalanche, or to integrate with the ZavaX bridge we are building, or in other ways that we have not yet imagined.

We are honored to have this opportunity to connect two of our favorite blockchains! Thank you @ZcashGrants for the funding. Also thank you to the Ava Labs developer relations team for your support. It is also humbling to see on Twitter the founders of both Zcash and Avalanche taking an interest in our shared success.

[mrkit2u]

Over the weekend we tested upgrading the ZavaX subnet VM. Everything went smoothly! Along the way, we rolled out two changes into production.

1. We changed the method name from zcash.getBlockByHeight to zavax.getBlockByHeight. Functionality is exactly the same.

2. We fixed a bug/defect. In the case of a Zcash chain split, and in the case of the majority of the ZavaX nodes not being on the eventual winning side of the split, an incorrect block would have been added to ZavaX. We have added a rule that does not allow Zcash block data to be added to ZavaX until it is over 24 blocks deep.

A big thank you to a Zcash community member for asking the question that led us to resolving this defect.

---

I hope to see some of you at Zcon4 this weekend. You can find me by looking for this ZavaX pin on my shirt and ZavaX sticker on my computer. Would love to chat! Also, I will have a limited supply of both with me at the conference, so if you would like one, hmu for one of these historical markers!

[Milton]

Will the bridge be designed with ZSAs in mind? We might want to support bridging for instance stablecoins from Avalanche to Zcash when ZSAs are implemented.

[mrkit2u]

Hi Milton. Version 1.0 will not support ZSAs, but bridging them is certainly on the roadmap. Lots of potential here.

[mrkit2u]

Hello! An update on the ZavaX bridge is overdue, but before this, we did not have much more to report than, “We’re continuing to work on combining technologies into a new bridge design.” Building ZavaX is a creative process. We are building on the shoulders of giants, but a bridge exactly like this one has not yet been built. It’s taking some time to think through the design particulars carefully.

Now we have a finding that is worth sharing: after careful consideration, we will not be using Intel SGX technology in the ZavaX bridge. It is not needed, and as such, using it would be adding a bit of “security theater” to the bridge while actually slightly harming its security.

The design of the ZavaX bridge is inspired by Ava Labs’ Bitcoin-Avalanche bridge which uses SGX, so that is why we had initially thought that we would use SGX for ZavaX. But the Bitcoin-Avalanche bridge is a centralized bridge running on one computer that was created before Avalanche subnets existed. Its designers wanted to decentralize its operation somewhat for added security in spite of subnets not yet being available, so they leveraged SGX secure enclave technology to accomplish this task.

Their bridge consists of one centralized computer with an Intel SGX enclave that runs the bridge code. The bridge computer cannot move funds on its own; it requires the signatures of six out of eight trusted bridge Wardens. None of the Wardens have direct access to the bridge computer, and yet each needs to be sure that it is indeed communicating with the real bridge, and that the bridge computer’s code has not been compromised.

This is where SGX technology is useful. The Bitcoin-Avalanche bridge’s SGX enclave signs each request to Wardens, proving that the code it just used to make the request is the same trusted code that has made previous requests (this is called “remote attestation”). The Wardens can then accept or reject each bridge transaction, assured of its integrity.

The ZavaX bridge, however, while inspired by the Bitcoin-Avalanche bridge, will use an Avalanche elastic subnet for decentralized security, and as such does not need SGX at all. Design elements:

1. Every subnet validator is a Warden, and there is no centralized bridge computer.
2. With the ZavaX bridge, any Warden can be a transaction Initiator, proposing a transaction to the ZavaX bridge subnet, and because the Wardens are in a subnet together, they are already authenticated to each other.
3. Every Warden is running both Avalanche and Zcash nodes, so each has equal knowledge of what has transpired on both platforms.

Since the ZavaX bridge is a subnet—a mini proof-of-stake blockchain—it inherits all the security properties of blockchains. As with all PoS blockchains, there is no need for any validator/Warden to trust the code running on any other validator/Warden’s computer because as with all PoS blockchains, a super-majority rules, and the subnet’s transaction valid/invalid decision can only produce wrong answers if a super-majority of validators/Wardens are byzantine and cheat.

Because there is no centralized computer in the ZavaX bridge, no one computer needs to attest to the others that it is running trusted code. If one Warden does run rogue code that produces false results, the subnet’s other Wardens will simply overrule it, and punitive measures may be taken by the subnet (such as temporarily banning, slashing, and/or permanently banning).

Since SGX is not needed for security, avoiding using it has three advantages:

1. Simple and clean bridge design is key—for pragmatic reasons. Clean code is easier to audit; each added technology and complexity brings with it risk. Bridges are inherently high-risk. KISS.
2. Intel SGX technology is not perfect. There are known side-channel attacks that can steal private keys under some circumstances. Not including SGX removes the possibility of these attacks.
3. This means that the ZavaX bridge won’t have dependence on a single corporation (Intel) for it to remain functioning. A ZavaX bridge validator/Warden will be able to run on any computer—with some minimum system requirements of course—that can run Linux.

---

We considered including Intel SGX technology in the ZavaX bridge design with the best of intentions, based on its use in the Bitcoin-Avalanche bridge. However, we have concluded that because of ZavaX has evolved past centralized security to using blockchain security, the right path forward is to exclude it and build a better bridge. Onward!

@ZcashGrants

[Milton]

I am very skeptical of any bridge where an attacker can simply buy a certain amount of stake to steal funds. My impression was that this bridge was supposed to use SGX to make validators operate entirely inside the secure enclave, and thus force attackers to both compromise SGX and buy enough stake to steal funds. It seems to me that now an actor like North Korea could simply cough up enough capital to steal all the funds inside the bridge.

[mrkit2u]

Yes, for sure, this is a serious risk to mitigate, common with new blockchains. Just imagine if the US government had had the foresight to mine and buy up all the bitcoin it could starting in 2010. We have thought about this risk, and I also discussed it with a few people at Zcon4. You can eliminate it the short run and mitigate it in the long run by making smart choices in three areas:

1. Initial token distribution. Get tokens into the hands of parties who have a interest in the success of ZavaX. For instance, The Zcash Foundation, The Electric Coin Company, The Avalanche Foundation, Ava Labs, red·dev, etc. They will continue to hold the staking token regardless of its price, in order to block an existential threat.

2. Unlocking. Lock the vast majority of tokens on launch, and then gradually unlock tokens so that they can be bought and sold over time.

3. Threshold choice. For instance, if 80% of stake is necessary for a bridge transaction approval, that means that as long as honest validators/Wardens control at least 20% of the stake, no money can be stolen from the bridge. That threshold can be adjusted up or down.

Bridges are high-risk projects, but I believe that with careful implementation, we can keep the bridge safe through launch and beyond. However, because this is an emergent technology, it is difficult to predict what changes will need to be implemented in the future. ZavaX is an open source project, and we welcome ideas and contributions from the community.