Zcash Elastic Subnet Bridge on Avalanche

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

[Milton]

This pretty much limits us to creating a new token though. And a lot of decentralization compared to normal multisig bridges is lost if we are actively going to rely on these orgs to veto malicious actors.

[mrkit2u]

I am pleased to report that we have completed Milestone 2 of the ZavaX Zcash-Avalanche Elastic Subnet Bridge project. Please take a look at our GitHub repo here! This fulfills Deliverable 2.1.

We have worked to make the architecture documentation accessible to as wide an audience as possible:

• README files throughout that provide commentary on the design.
• Clear annotated UML diagrams.
• Normal English instead of jargon wherever possible.

Though the architecture does get technical at times despite our best efforts, I hope that we have succeeded in delivering something from which everyone can learn and reach a basic understanding of how this bridge works.

We have already begun work on Milestone 3, and it is going well so far. Staying on schedule has been a challenge with this project, but we will be building as fast as we can, all the while prioritizing quality and security the highest. Here are revised milestone estimated completion dates, fulfilling Deliverable 2.2:

Milestone 3 March 31, 2024

• Deliverable 3.1 - Support for bridging ZEC to ZEC.z in both directions on testnets, with a one-validator Subnet, to C-Chain (assuming supported) or Subnet
• Deliverable 3.2 - UX and UI design for GUI completed

Milestone 4 April 30, 2024

• Deliverable 4.1 - Fully functional deployment to Zcash and Avalanche testnets, with a 3-validator Subnet, with CLI support

Milestone 5 May 31, 2024

• Deliverable 5.1 - GUI: bridge integration into Core or webapp

Milestone 6 June 30, 2024

• Deliverable 6.1 - Successful pass of software audit
• Deliverable 6.2 - Publishing of the audited source code to a public Github repo

---

I would like to give a special thanks to @pacu for consulting with us over the past month during the home stretch. Your advice has been invaluable. Also thank you to technical leaders of other Avalanche projects for your review prior to publication. You know who you are! Finally, thank you to @ZcashGrants for your continued support. This project would not be possible without you.

This is an open source project. If you would like to contribute, please reach out, and let’s coordinate.

I am traveling this week, so I am not online as much as normal, but I will try to respond thoughtfully to questions and comments within a day or two! Enjoy.

[mrkit2u]

The ZavaX Oracle subnet has been up for over three months now! We started by building an oracle because it is a necessary element of a financial bridge.

It runs on three nodes on the Avalanche Fuji Testnet. Fuji runs exactly the same Avalanche node software as the mainnet, just with test AVAX tokens that have no value.

Since launch, the Avalanche network has gone through many minor and one major upgrade. The major upgrade required revisions to the ZavaX Oracle custom virtual machine which we made last month and have just released on GitHub.

We have also added a Recheck All Blocks feature to the user interface so that anyone can quickly verify that each node of the oracle has performed flawlessly for lookup of over 4,538 Zcash blocks since launch. Simply select a node and then press the button. The check takes about 15 seconds to run. This is deliverable 3.3.

In other news, we are seriously considering integrating the Zcash Foundation’s new FROST software for threshold signature verification, and we are hardening the security of the subnet to prevent attacks. More about these two items soon.

https://zavax-oracle.red.dev
Feel free to retweet: https://twitter.com/reddevinc/status/1772266079189913646

[zkcroc]

You’re about 1 month ahead of schedule according to your grant proposal, well done!

Does this mean we’re only approx 3 months from a full working bridge?

[mrkit2u]

Thanks, but not really a month ahead! We are working on different parts at the same time, and just because we deliver one part ahead of schedule does not mean that everything else is ahead too! I wish! The timeline presented in the grant proposal is our current best estimation. However, as I think we all know here, estimations of software completion dates are notoriously challenging to get right.

[zkcroc]

That’s fair, what is your ball park estimate for completion currently?

[mrkit2u]

Hello everyone, for our most recent update on the ZavaX project, please watch my presentation from last week at ZconV. It’s about 15 minutes with 10 minutes of questions. Please feel free to post any follow-up questions here, and I’ll respond as soon as I’m able!

[mrkit2u]

Quick informal poll!

If you like the name ZavaX for the Zcash-Avalanche bridge that we are building, please like this reply.

If not, please like the reply below this one.

[mrkit2u]

If you dislike the name ZavaX for the Zcash-Avalanche bridge that we are building and think we should come up with another name, please like this reply.

[Jackofswords]

‘Zavalanche bridge’