Zcash Elastic Subnet Bridge on Avalanche

The incentives are perhaps better aligned with a new token, but the market cap of ZAX would likely be much lower than that of ZEC, and I think the economic security would likely be lower as well. I think there would be a lot of people holding ZEC willing to bridge it over to stake, but who would not be inclined to do so if they had to buy another token. Ultimately, I think it is better for the Zcash ecosystem to have ZEC.z as the staking and gas token.

There already was a guy who ported the Zcash protocol over to an Avalanche subnet. RFI – Zapa - Community Grants / RFI - RFP Grants - Zcash Community Forum. Apparently it was working on testnet, but has since been abandoned. I don’t think combining this with a bridge to Zcash is an unreasonably large project. Maybe you can even collab with the guy?

1 Like

I am so pleased to see that this project proposal is generating a discussion. This project has been in the back of my mind for our team for over a year, so it’s exciting for me to see the community engaging with it now. I’ll give some more thoughts and responses.

Bridge Subnet + Shielded Zcash Subnet

In our initial discussions about this project, the idea was to create a Subnet to handle bridging with support for bridging to the C-Chain, but to leave the architecture open enough to allow anyone else to also bridge to their Subnet as well. With Prof. Matthew Green’s interest in supporting shielded transactions on Avalanche (and as Milton points out, another project is already part way there) it does make sense to me to make sure these two projects (and two Subnets) can function together harmoniously. I do think that architecturally the way to implement this is with two Subnets (as described earlier). As far as project scope, it seems like there are a few options, and we are open to finding a project scope that works for the Grants Committee.

Tokens and Staking

Shielded Zcash Subnet

For the shielded Subnet running the Zcash chain, it makes sense to me to use ZEC.z as the staking and gas token, as Matt suggests. (By the way, I’m using the naming convention for ZEC.z that Avalanche uses for its bridged tokens. For instance, BTC.b, USDC.e, etc.) This is a win all around for the reasons that he describes.

Bridge Subnet

For the Zcash-Avalanche Bridge Subnet, I see from our discussion here that the staking token is perhaps the most controversial aspect of this project, so let me put some more time into explaining our reasoning behind creating a ZAX token for this purpose.

As described earlier, we propose that it be used for both staking and gas, but one thing also worth pointing out is that new ZAX would also be minted and then distributed as rewards to validators for participating in the Subnet.

The vision here is for the Bridge Subnet to follow the model that successful blockchains have already implemented and to avoid reinventing the wheel. This Bridge Subnet really is a small blockchain with all the benefits and complications that that entails, and by far the safest path is the path well-trod.

Pkr’s idea of providing ZAX proportionally to all Zcash holders appeals to me more and more, and this would also simplify the user experience when using the bridge. Fresh ZAX would be minted as users bridged ZEC to ZEC.z and would be automatically deposited into their wallets on the Avalanche side, with a small amount deducted for bridging fees. Bridge users would then have a choice what to do with the rest of their ZAX. Stake it? Save it for future transactions? Sell it? We would want to implement a locking period for ZAX to prevent a fast sell-off, but eventually everyone should be able to sell all their ZAX to others who would like to buy it. I could see this being very appealing to perspective bridge users: use the bridge, claim their ZAX, and initiate its unlocking clock. What a great way to organically get the community trying out the bridge!

To Zcash users who normally just think about one token, ZAX may seem unnecessarily complicated from a user experience point-of-view, but I assure you that once you’ve entered the Avalanche ecosystem, dealing with multiple special-purpose tokens is the norm; many projects have one.

Over the longer term, we envision that red·dev would take on the role of a smaller Electric Coin Company for this Bridging Subnet, and like the them, red·dev will require a dependable income stream. This is another reason to create ZAX, as a portion of staking rewards can be apportioned to red·dev. Also, ZAX aligns incentives; the more successful the bridge, the bigger the rewards. This also frees up the Grants Committee from ongoing funding; all this project requires is seed funding.

Along the same lines, not using ZAX raises another issue. If we were to use another token for staking—say AVAX or ZEC.z—the Bridge Subnet would have to pay rewards in this currency, and because we can’t mint it, a supply would have to be bought, diverted, or financed, creating a host of new questions and problems. For instance:

  • What is the source of these funds?
  • As values of tokens and bridge use fluctuates over time, how are adjustments made to staking requirements and reward amounts? If these must be done manually, who is responsible?

Another issue with using a token besides ZAX as the staking token is that the Subnet would have to implement slashing of funds for malfunctioning or misbehaving validators. Avalanche has avoided implementing slashing (the only funds at risk are your potential rewards). As someone who has run an Avalanche validator, let me tell you what a wonderful thing this is not to live under the specter of slashing day in and day out. Avalanche has been able to do this successfully because they are using the AVAX token for staking, and everyone realizes that if the Avalanche network were to malfunction or to be successfully attacked, the value of AVAX would plummet—in effect platform-wide slashing. This keeps everyone incentivized to validate the network with care and integrity. Some fudders have been skeptical that this would work, but at this point, the Avalanche platform has proven itself.

However, if Avalanche were to stake its validators with another token, say for instance BTC.b, the same incentives would not be in place. An Avalanche validator could misbehave with no concerns about tanking the price of bitcoin. The only way then to enforce good behavior would be to threaten to slash each validator’s BTC.b.

We would face a similar problem if another token besides ZAX were used to stake the Bridge Subnet. We would have to implement slashing of that other token in order to enforce good validator behavior. This is a huge minus imo, especially in the Avalanche ecosystem where the norm is no slashing.

An International Bridge

As we talk here in a Zcash forum, it’s easy to think of this bridge as a “Zcash property,” but in fact, this bridge is connecting two sovereign platforms, just like the Peace Bridge connects the US and Canada. I’d urge that everyone take on this mindset. Both platforms will benefit, and it serves both communities. Whereas the Shielded Zcash Subnet that Matt proposes would be much more closely connected to Zcash (with 1:1 pegging, etc.), this Bridge Subnet serves as a way station to parts of Avalanche that have nothing to do with Zcash as of yet and may not even yet exist. This “international” aspect is yet another reason to use an independent token for staking the Bridge Subnet validators.

Custody of Funds

Both Matt and Milton have raised an important security concern about funds custody. These wallets and smart contracts could become large honeypots indeed. Avalanche’s SGX Bitcoin bridge does something interesting to mitigate this problem. On the bitcoin side, it does keep the bridged bitcoin in a wallet, but on the Avalanche side, it never takes custody of the BTC.b. Each user’s BTC.b is protected by the same private key as secures their bitcoin wallet. These cryptography gymnastics are done by having the user sign some data with their bitcoin private key, then extracting their public key from the signature, and then using that public key to create a wallet on the Avalanche side that only the user’s bitcoin private key can unlock. (My team is familiar with this kind of thing already, as we had to use a similar technique to verify an X-Chain digital signature on the C-Chain for the tutorials that we wrote.) I’m sure there are other ways to further protect bridge assets, but I think it would be a good idea to start with something like this, especially considering the similarities between Zcash and bitcoin.


OK, that was a long one! :smiley:

I think is worth it writing all this down though as it helps us think about these issues clearly and in a documented manner. Thank you so much for the comments so far. We will be submitting a formal proposal soon.

4 Likes

For the source of these funds, they can simply be paid out of gas fees can’t they?

As for staking requirements (I am assuming you are talking about minimum stake required), why would we need a minimum staking amount? One of the advantages of Avalanche is that it can handle many thousands of validators, which I think we should take advantage of, and the AVAX required to become a validator will serve as an upper limit anyway.

Hey @mrkit2u would love to chat with you on this, we’re pretty deeply familiar with ZEC and possible bridge implementations for it AND we recently have been quite excited about the developments happening with AVAX Subnets.

It seems like there are a lot of parts that need to be built, we could possibly collaborate.
My telegram is @jommi, lets chat!

1 Like

Hi, just getting back to answering now.

Yes, you’re right, Milton, it could work that way, so perhaps that wasn’t my strongest point of the bunch!

One great development this week is from the Avalanche side in yesterday’s Avalanche Community Developer Call. The link joins about 2/3 of the way through, and if you’re really in tl;dr mode, skip to 51:10 and listen to what Patrick and Aaron say at the end. They are describing how a bridge exactly like this one would work on the Avalanche side, would be easy to implement, and could integrate ZK proofs as well.

What I got out of this discussion is that the platform team at Ava Labs is ready (and excited) to support a bridge of this type with their newly released Subnet and AWM tech.

4 Likes

We have submitted a formal proposal to the Zcash Community Grants Committee, and you can view it here:

We have narrowed the scope to building the bridge software and deploying it to testnets. This would allow us to begin building while discussions continue about how to fully deploy it to connect the Zcash and Avalanche mainnets (Part 2), and about how to connect it to a new Zcash-on-Avalanche Subnet (Part 3).

Thank you for your consideration.

Kit

@ZcashGrants

10 Likes

200k is enormous, and we don’t have the guarantee that demand will be there… However, this is a good idea. This grant should also try to convince people like Barry Silbert to seed a decent sized liquidity pool so people can actually do things with their Zec.

Without such commitment, I don’t like this grant because Zcash community is paying high price for no tangible roi.

4 Likes

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?

2 Likes

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.

  1. 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.

  2. 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.

  3. 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

  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?
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.

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

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.

  1. 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.

  1. 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.

  1. 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