Totally agree on that point. I would like to see some figures of the intersection of potential new users this would bring to Zcash. If anything else, this seems heavily weighted to providing more value to Avalanche than Zcash. How many people would this even target?
1 Like
Well, we could knock $30K off by not doing an audit during Part 1. The per hour rate is low, much lower than other projects that have been funded.
There’s huge ROI in being connected to other ecosystems. The Avalanche-Bitcoin bridge now has more BTC in it than Lightning, for instance, all because it allows BTC hodlers to use their BTC to participate in defi without selling their BTC. See Bitcoin-Bridged to Avalanche Reaches Record Daily Mint of Over 2K BTC.
It also would allow for the use case of keeping your savings private in shielded ZEC and then bridging it for financial activities, and then returning it to shielded ZEC for privacy. This is compelling to me as this is not possible yet.
No harm in appealing to Avalanche users; they’ll be buying ZEC. That’s good for Zcash.
6 Likes
Thank you for submitting this. Bridges like these are critical to the future of Zcash and growing its base of users. That being said, I’d be interested in commentary from team members at ECC/ZF/ZOMG.
6 Likes
If I am not mistaken, after Ren Protocol was shut down, there are now 0 decentralized bridges to Zcash. The fact that a privacy preserving coin has no decentralized bridge from another major chain is a huge risk that needs to be fixed as soon as possible. If Zcash was banned tomorrow, there would be no way for most people to get ZEC.
7 Likes
I had a productive meeting with @ZcashGrants on Friday afternoon in which I answered some questions, and we discussed the proposed bridge. I’ll describe here two subjects that we discussed that I think others in the community would find interesting: how the proposed bridge would work, and some differences between this bridge and THORChain.
Our Bridge Design
It’s conventional wisdom that you need a trusted third party to bridge assets between two cryptocurrency platforms. For instance, the Bitcoin-Avalanche bridge uses bridging code running in an SGX enclave on a server, and a committee of eight trusted “wardens”—trusted third parties designated by the Avalanche Foundation—approves or denies bridge transfers.
Our proposed bridge uses a similar architecture to this bridge, but the wardens are replaced by Subnet validators, each maintaining its own secure enclave, and the Subnet itself becomes the trusted third party. We know it can be trusted because it has the same security structure as any PoS blockchain, and we trust blockchains. The Subnet is “elastic”—permissionless—so anyone can become a warden/validator just by staking enough of the staking token.
By the way, because the bridge must be a third party—disjoint from either blockchain—this is why you can’t just combine the bridging Subnet (Part 1) with the Zcash-on-Avalanche Subnet (Part 3). The bridge must be in its own Subnet.
THORChain
Later in our conversation, we touched on THORChain which is another way to transfer value between platforms, and a THORChain implementation is being built for Zcash. THORChain is cool because it would allow you to convert your ZEC on Zcash into AVAX on Avalanche—native token to native token. It would do this by maintaining asset pools of both ZEC and AVAX, and THORChain regulates the flow in and out of these pools to bridge assets between platforms.
The coolest thing about THORChain to me is that you are issued the native asset—not a wrapped asset—on the remote chain. But there are some things that our proposed bridge will do substantially better than THORChain which I will elaborate on here.
-
Maintain robustness when networks are stressed. Because THORChain uses liquidity pools, under periods of high network stress where there is a “rush for the exits,” THORChain’s pools could become depleted, causing its bridge to halt. With our proposed bridge, this is not possible. Holders of ZEC.z always will be able to bridge back to ZEC because their ZEC is just sitting there locked on the Zcash side, waiting for them.
-
Architecturally, ours will be able to support shielded transactions. With the completion of Part 3, it will be possible to bridge shielded ZEC from Zcash to Zcash-on-Avalanche. This is an architectural impossibility with THORChain.
-
Supports cross-chain querying. To me, this is the stealth feature that may even turn out to be better than asset bridging. One possible use case would be to ask the bridge, from any Avalanche Subnet, what just happened on Zcash. By combining this capability with Zcash’s shielded transaction feature, you would be able to use shielded transactions—for instance by using the encrypted memo field—to privately signal events to Avalanche smart contracts. I realize this is a bit vague and hand-wavy at this point, but I think could be huge.
Not trying to FUD THORChain at all with this assessment by the way. Just pointing out that the different technologies better serve different use cases. Another bridging tech, Layer Zero, is also cool, and it works in yet another completely different way, but it is only can support transfers if both chains can run smart contracts, so it can’t support Zcash.
If anyone has questions or comments about what I’ve written here or anything else, feel free to add your two cents. I was told that the Committee will be discussing this Zcash-Avalanche Bridge proposal at its meeting a week from today.
5 Likes
By the way, because the bridge must be a third party—disjoint from either blockchain—this is why you can’t just combine the bridging Subnet (Part 1) with the Zcash-on-Avalanche Subnet (Part 3). The bridge must be in its own Subnet.
I don’t understand this point. Why must the bridge be a third party? I mean there is nothing stopping the validators of the “Zcash-subnet” from also validating the “bridging subnet”
I have only a partial understanding myself, Milton. The problem is that neither blockchain has enough incentive to be honest enough to operate a bridge to another chain. I would like someone to explain this in more detail myself, as I have read it many times, but I don’t have the exact proof in my head, but that’s the general idea. Some computer scientist has written a proof of this somewhere.
Couldnt part 3 just be AVAX C-Chain, if collaboration from Ava Labs was secured?
On the C-Chain, you can have a token created when value comes across the proposed Zcash-Avalanche bridge. I’ve been calling it ZEC.z. But the C-Chain is an EVM chain, so there is no shielding at all. If you want to bridge to a shielded chain, you have to create a Subnet. But that’s just what Subnets were made for–custom plug-and-play blockchains adjacent to the main chains and all other Subnets. Their architecture is very open. Another project has already gotten us part way through Part 3, though at the moment it is stalled due to lack of funding.
BTW this is all permissionless. Support from Ava Labs would be great (for speed of development, networking with other projects, etc.) but is not necessary, even for adding ZEC.z to the C-Chain.
1 Like
Ahh I see it now. So we need an in-between subnet to handle the privacy aspect.
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
- 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?
- 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?
- 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)?
- 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?
- 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?
- Does part 1 code base completes an integration with testnets only?
8 Likes
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.
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
- 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.
- 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.
- 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.
- 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.
3 Likes
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
5 Likes
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.
-
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.
-
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
3 Likes
@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.
16 Likes
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?
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
5 Likes
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! 
7 Likes
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.
4 Likes